home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-07-10 | 571.0 KB | 11,779 lines |
- [ PROTOCOLS:NBSOSI-AGREEMENTS.DOC ] [ 8/88 ]
-
- Computer Science and Technology
- NBS Special Publication 500-150
-
- Stable Implementation Agreements for Open Systems Interconnection Protocols
- Version 1 Edition 3
- December 1987
-
- Based on the Proceedings of the NBS Workshop for Implementors of OSI
-
- U.S. Department of Commerce
- C. William Verity, Secretary
-
- National Bureau of Standards
- Ernest Ambler, Director
- Issued January 1988
-
-
-
- Table of Contents
-
- 1. GENERAL INFORMATION . . . . . . . . . . . . . . . . . . . . . . . 1
- 1.1 PURPOSE OF THIS DOCUMENT . . . . . . . . . . . . . . . . . . 1
- 1.2 PURPOSE OF THE WORKSHOP . . . . . . . . . . . . . . . . . . 1
- 1.3 WORKSHOP ORGANIZATION . . . . . . . . . . . . . . . . . . . 2
-
- 2. SUB NETWORKS . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
- 2.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
- 2.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 2.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 2.5 LOCAL AREA NETWORKS . . . . . . . . . . . . . . . . . . . . 1
- 2.5.1 IEEE 802.2 LOGICAL LINK CONTROL . . . . . . . . . 1
- 2.5.2 IEEE 802.3 CSMA/CD ACCESS METHOD . . . . . . . . . 2
- 2.5.3 IEEE 802.4 TOKEN BUS ACCESS METHOD . . . . . . . . 3
- 2.5.4 IEEE 802.5 TOKEN RING ACCESS METHOD . . . . . . . 3
- 2.6 WIDE AREA NETWORKS . . . . . . . . . . . . . . . . . . . . . 5
- 2.6.1 CCITT RECOMMENDATION X.25 . . . . . . . . . . . . 5
-
- 3. NETWORK LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
- 3.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
- 3.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 3.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 3.5 CONNECTIONLESS-MODE NETWORK SERVICE (CLNS) . . . . . . . . . 1
- 3.5.1 Provision of CLNS over Local . . . . . . . . . . . 1
- 3.5.2 Provision of CLNS over X.25 Subnetworks . . . . . 1
- 3.5.3 Agreements on Protocols . . . . . . . . . . . . . 2
- 3.5.3.1 ISO 8473 . . . . . . . . . . . . . . . . . . 2
- 3.5.3.2 Subnetwork Dependent Convergence Function . . 3
- 3.6 CONNECTION-MODE NETWORK SERVICE (CONS) . . . . . . . . . . . 3
- 3.6.1 Mandatory Method of Providing CONS . . . . . . . . 3
- 3.6.2 Additional Option: Provision of CONS over X.25 1980
- Subnetworks . . . . . . . . . . . . . . . . . . . 3
- 3.6.3 Agreements on Protocols . . . . . . . . . . . . . 4
- 3.6.3.1 ISO 8878 . . . . . . . . . . . . . . . . . . 4
- 3.6.3.2 Subnetwork Dependent Convergence Protocol (ISO
- 8878/Annex A) . . . . . . . . . . . . . . . . 4
- 3.7 ADDRESSING . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3.8 ROUTING . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.8.1 Static Routing . . . . . . . . . . . . . . . . . . 5
- 3.8.2 End System to Intermediate System . . . . . . . . 5
- 3.9 MIGRATION CONSIDERATIONS . . . . . . . . . . . . . . . . . . 6
- 3.9.1 X.25-1980 . . . . . . . . . . . . . . . . . . . . 6
- 3.10 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 7
-
- 4. TRANSPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 4.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
- 4.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
- 4.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 4.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 4.5 TRANSPORT CLASS 4 . . . . . . . . . . . . . . . . . . . . . 1
- 4.5.1 Transport Class . . . . . . . . . . . . . . . . . 1
- 4.5.2 Protocol Agreements . . . . . . . . . . . . . . . 1
- 4.5.2.1 Rules for Negotiation . . . . . . . . . . . . 1
- 4.5.2.2 Transport Class 4 Service Access Points or
- Selectors . . . . . . . . . . . . . . . . . . 3
- 4.5.2.3 Retransmission Timer . . . . . . . . . . . . 3
- 4.5.2.4 Keep-Alive Function . . . . . . . . . . . . . 4
- 4.6 TRANSPORT CLASS 0 . . . . . . . . . . . . . . . . . . . . . 6
- 4.6.1 Transport Class 0 Overview . . . . . . . . . . . . 6
- 4.6.2 Protocol Agreements . . . . . . . . . . . . . . . 6
- 4.6.2.1 Transport Class 0 Service Access Points . . . 7
- 4.6.3 Rules for Negotiation . . . . . . . . . . . . . . 7
-
- 5. UPPER LAYERS . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 5.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
- 5.1.1 References . . . . . . . . . . . . . . . . . . . . 1
- 5.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
- 5.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 5.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 5.4.1 ISO Defect Reports . . . . . . . . . . . . . . . . 2
- 5.4.2 Session Defects . . . . . . . . . . . . . . . . . 2
- 5.5 ASSOCIATION CONTROL SERVICE ELEMENT . . . . . . . . . . . . 2
- 5.5.1 Introduction . . . . . . . . . . . . . . . . . . . 2
- 5.5.2 Services . . . . . . . . . . . . . . . . . . . . . 3
- 5.5.2.1 ACSE Services . . . . . . . . . . . . . . . . 3
- 5.5.2.2 Use of Presentation Layer Services . . . . . 3
- 5.5.3 Protocol agreements . . . . . . . . . . . . . . . 3
- 5.5.3.1 Application Context . . . . . . . . . . . . . 3
- 5.5.3.2 Section Deleted . . . . . . . . . . . . . . . 4
- 5.5.3.3 AE Title . . . . . . . . . . . . . . . . . . 4
- 5.6 PRESENTATION . . . . . . . . . . . . . . . . . . . . . . . . 4
- 5.6.1 Introduction . . . . . . . . . . . . . . . . . . . 4
- 5.6.2 Services . . . . . . . . . . . . . . . . . . . . . 5
- 5.6.2.1 Presentation Services . . . . . . . . . . . . 5
- 5.6.2.2 Use of Session Layer Services . . . . . . . . 6
- 5.6.3 Protocol Agreements . . . . . . . . . . . . . . . 6
- 5.6.3.1 Transfer Syntaxes . . . . . . . . . . . . . . 6
- 5.6.3.2 Abstract Syntaxes . . . . . . . . . . . . . . 6
- 5.6.3.3 Presentation Context Identifier . . . . . . . 6
- 5.6.3.4 Mode-selector Position in SET . . . . . . . . 7
- 5.6.3.5 Default Context . . . . . . . . . . . . . . . 7
- 5.6.3.6 P-Selectors . . . . . . . . . . . . . . . . . 7
- 5.6.3.7 Provider Abort Parameters . . . . . . . . . . 7
- 5.6.3.8 Provider Aborts and Session Version . . . . . 7
- 5.6.3.9 CPC-type . . . . . . . . . . . . . . . . . . 7
- 5.6.3.10 Presentation-context-definition-result-list . 8
- 5.6.3.11 RS-PPDU . . . . . . . . . . . . . . . . . . . 8
- 5.6.4 Presentation ASN.1 Encoding Rules . . . . . . . . 8
- 5.6.4.1 Invalid Encoding . . . . . . . . . . . . . . 8
- 5.6.4.2 Protocol-version, Presentation-requirements . 8
- 5.6.4.3 Presentation-selector . . . . . . . . . . . . 8
- 5.7 SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5.7.1 Introduction . . . . . . . . . . . . . . . . . . . 8
- 5.7.2 Services . . . . . . . . . . . . . . . . . . . . . 9
- 5.7.2.1 Session Services . . . . . . . . . . . . . . 9
- 5.7.2.2 Use of Transport Services . . . . . . . . . . 9
- 5.7.3 Protocol Agreements . . . . . . . . . . . . . . . 9
- 5.7.3.1 Concatenation . . . . . . . . . . . . . . . . 9
- 5.7.3.2 Segmenting . . . . . . . . . . . . . . . . . 10
- 5.7.3.3 Reuse of Transport Connection . . . . . . . . 10
- 5.7.3.4 Use of Transport Expedited Data . . . . . . . 10
- 5.7.3.5 Use of Session Version Number . . . . . . . . 10
- 5.7.3.6 Receipt of Invalid SPDUs . . . . . . . . . . 11
- 5.7.3.7 Invalid SPM Intersections . . . . . . . . . . 11
- 5.7.3.8 S-Selectors . . . . . . . . . . . . . . . . . 11
- 5.8 UNIVERSAL ASN.1 ENCODING RULES . . . . . . . . . . . . . . . 11
- 5.8.1 Tags . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.8.2 Definite length . . . . . . . . . . . . . . . . . 12
- 5.8.3 EXTERNAL Type . . . . . . . . . . . . . . . . . . 12
- 5.9 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.9.1 Specific ASE Requirements for ACSE Presentation and
- Session . . . . . . . . . . . . . . . . . . . . . 12
- 5.9.1.1 FTAM . . . . . . . . . . . . . . . . . . . . 13
- 5.9.1.1.1 Phase 2 . . . . . . . . . . . . . . . . 13
- 5.9.1.2 MHS . . . . . . . . . . . . . . . . . . . . . 15
- 5.9.1.2.1 Phase 1 . . . . . . . . . . . . . . . . 15
- 5.9.1.3 DS . . . . . . . . . . . . . . . . . . . . . 16
- 5.9.1.3.1 Phase 1 . . . . . . . . . . . . . . . . 16
- 5.10 APPENDIX A: RECOMMENDED PRACTICES . . . . . . . . . . . . . 17
-
- 6. ISO FILE TRANSFER, ACCESS AND MANAGEMENT PHASE 2 . . . . . . . . 1
- 6.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
- 6.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
- 6.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 6.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 6.5 ASSUMPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 4
- 6.6 PRESENTATION AGREEMENTS . . . . . . . . . . . . . . . . . . 5
- 6.7 SERVICE CLASS AGREEMENTS . . . . . . . . . . . . . . . . . . 6
- 6.8 FUNCTIONAL UNIT AGREEMENTS . . . . . . . . . . . . . . . . . 6
- 6.9 FILE ATTRIBUTE AGREEMENTS . . . . . . . . . . . . . . . . . 6
- 6.9.1 Mandatory Group . . . . . . . . . . . . . . . . . 7
- 6.9.2 Optional Groups . . . . . . . . . . . . . . . . . 7
- 6.10 DOCUMENT TYPE AGREEMENTS . . . . . . . . . . . . . . . . . . 8
- 6.10.1 Character Sets . . . . . . . . . . . . . . . . . . 11
- 6.10.1.1 IA5 Character Set . . . . . . . . . . . . . . 12
- 6.10.1.2 8859-1 Character Set . . . . . . . . . . . . 14
- 6.10.2 Document Type Negotiation Rules . . . . . . . . . 14
- 6.10.2.1 Connection Establishment . . . . . . . . . . 14
- 6.10.2.2 File Creation . . . . . . . . . . . . . . . . 14
- 6.10.2.3 File Opening . . . . . . . . . . . . . . . . 14
- 6.10.3 Relationship Between DUs, DEs and Document Types . 15
- 6.11 F-CANCEL ACTION . . . . . . . . . . . . . . . . . . . . . . 16
- 6.12 IMPLEMENTATION INFORMATION AGREEMENTS . . . . . . . . . . . 16
- 6.13 DIAGNOSTIC AGREEMENTS . . . . . . . . . . . . . . . . . . . 16
- 6.14 CONCURRENCY . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.15 REQUESTED ACCESS . . . . . . . . . . . . . . . . . . . . . . 18
- 6.16 SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 6.16.1 Initiator Identity and Filestore Password . . . 19
- 6.16.2 Access Passwords . . . . . . . . . . . . . . . . 19
- 6.16.3 Implementation Responsibilities . . . . . . . . . 19
- 6.17 REQUIREMENT FOR CONFORMANT IMPLEMENTATIONS . . . . . . . . . 19
- 6.17.1 Interoperable Configurations . . . . . . . . . . . 20
- 6.17.2 Relationship to ISO 8571--The FTAM Standard . . . 21
- 6.17.3 Requirements for Document Type Support . . . . . . 21
- 6.17.4 Initiators . . . . . . . . . . . . . . . . . . . . 22
- 6.17.5 Responders . . . . . . . . . . . . . . . . . . . . 23
- 6.17.6 Senders . . . . . . . . . . . . . . . . . . . . . 24
- 6.17.6.1 Initiator Senders . . . . . . . . . . . . . . 25
- 6.17.6.2 Responder Senders . . . . . . . . . . . . . . 25
- 6.17.7 Receivers . . . . . . . . . . . . . . . . . . . . 25
- 6.17.7.1 Initiator Receivers . . . . . . . . . . . . . 26
- 6.17.7.2 Responder Receivers . . . . . . . . . . . . . 26
- 6.17.8 Minimum Ranges . . . . . . . . . . . . . . . . . . 26
- 6.17.9 Use of Lower Layer Services . . . . . . . . . . . 29
- 6.18 IMPLEMENTATION PROFILES . . . . . . . . . . . . . . . . . . 29
- 6.18.1 General Requirements for the Defined Implementation
- Profiles . . . . . . . . . . . . . . . . . . . . . 30
- 6.18.2 Intentionally Left Empty . . . . . . . . . . . . . 30
- 6.18.3 Document Type Requirements for the Defined
- Implementation Profiles . . . . . . . . . . . . . 30
- 6.18.4 Parameters for the Defined Implementation Profiles 31
- 6.18.5 Parameter Ranges for the Defined Implementation
- Profiles . . . . . . . . . . . . . . . . . . . . . 32
- 6.18.6 File Attribute Support for Implementations . . . . 32
- 6.19 PROVISION OF SPECIFIC FUNCTION . . . . . . . . . . . . . . . 35
- 6.19.1 Implementation Profile T1: Simple File Transfer . 35
- 6.19.2 Implementation Profile T2: Positional File Transfer 35
- 6.19.3 Implementation Profile T3: Full File Transfer . . 36
- 6.19.4 Implementation Profile A1: Simple File Access . . 37
- 6.19.5 Implementation Profile A2: Full File Access . . . 37
- 6.19.6 Implementation Profile M1: Management . . . . . . 38
- 6.20 HARMONIZATION . . . . . . . . . . . . . . . . . . . . . . . 38
- 6.21 APPENDIX A: FTAM DOCUMENT TYPES . . . . . . . . . . . . . 39
-
-
- 7. CCITT 1984 X.400 BASED MESSAGE HANDLING SYSTEM . . . . . . . . . 1
- 7.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
- 7.2 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 7.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 7.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 7.5 PRMD to PRMD . . . . . . . . . . . . . . . . . . . . . . . . 3
- 7.5.1 Introduction . . . . . . . . . . . . . . . . . . . 3
- 7.5.2 Service Elements and Optional User Facilities . . 4
- 7.5.2.1 Classification of Support for Services . . . 4
- 7.5.2.1.1 Support (S) . . . . . . . . . . . . . . 5
- 7.5.2.1.2 Non Support (N) . . . . . . . . . . . . 5
- 7.5.2.1.3 Not Used (N/U) . . . . . . . . . . . . . 6
- 7.5.2.1.4 Not Applicable (N/A) . . . . . . . . . . 6
- 7.5.2.2 Summary of Supported Services . . . . . . . . 6
- 7.5.2.3 MT Service Elements and Optional User
- Facilities . . . . . . . . . . . . . . . . . . . . 6
- 7.5.2.4 IPM Service Elements and Optional User
- Facilities . . . . . . . . . . . . . . . . . . . . 8
- 7.5.3 X.400 Protocol Definitions . . . . . . . . . . . . 9
- 7.5.3.1 Protocol Classification . . . . . . . . . . . 10
- 7.5.3.2 General Statements on Pragmatic Constraints . 10
- 7.5.3.3 MPDU Size . . . . . . . . . . . . . . . . . . 11
- 7.5.3.4 P1 Protocol Elements . . . . . . . . . . . . 11
- 7.5.3.4.1 P1 Envelope Protocol Elements . . . . . 11
- 7.5.3.5 ORName Protocol Elements . . . . . . . . . . 16
- 7.5.3.6 P2 Protocol Profile (Based on [X.420]) . . . 18
- 7.5.3.6.1 P2 Protocol - Heading . . . . . . . . . 19
- 7.5.3.6.2 P2 Protocol - BodyParts . . . . . . . . 21
- 7.5.3.6.3 P2 BodyPart Protocol Elements . . . . . 23
- 7.5.4 Reliable Transfer Server (RTS) . . . . . . . . . . 25
- 7.5.4.1 Implementation Strategy . . . . . . . . . . . 25
- 7.5.4.2 RTS option selection . . . . . . . . . . . . 25
- 7.5.4.3 RTS Protocol Options and Clarifications . . . 26
- 7.5.4.4 RTS Protocol Limitations . . . . . . . . . . 29
- 7.5.5 Use of Session Services . . . . . . . . . . . . . 31
- 7.5.6 Data Transfer Syntax . . . . . . . . . . . . . . . 31
- 7.6 PRMD to ADMD and ADMD to ADMD . . . . . . . . . . . . . . . 31
- 7.6.1 Introduction . . . . . . . . . . . . . . . . . . . 31
- 7.6.2 Additional ADMD Functionality . . . . . . . . . . 33
- 7.6.2.1 Relay Responsibilities of an ADMD . . . . . . 33
- 7.6.2.2 P1 Protocol Classification Changes . . . . . 34
- 7.6.2.3 O/R Names . . . . . . . . . . . . . . . . . . 34
- 7.6.2.4 P1 ADMD Name . . . . . . . . . . . . . . . . 35
- 7.6.3 Interworking with Integrated UAs . . . . . . . . . 35
- 7.6.4 Differences with Other Profiles . . . . . . . . . 35
- 7.6.4.1 TTC Profile . . . . . . . . . . . . . . . . . 35
- 7.6.4.2 CEPT Profile . . . . . . . . . . . . . . . . 36
- 7.6.5 Connection of PRMDs to Multiple ADMDs . . . . . . 36
- 7.6.6 Connection of an ADMD to a Routing PRMD . . . . . 36
- 7.6.7 Management Domain Names . . . . . . . . . . . . . 37
- 7.6.8 Envelope Validation Errors . . . . . . . . . . . . 37
- 7.6.9 Quality of Service . . . . . . . . . . . . . . . . 38
- 7.6.9.1 Domain Availability . . . . . . . . . . . . . 38
- 7.6.9.1.1 ADMD Availability . . . . . . . . . . . 38
- 7.6.9.1.2 PRMD Availability . . . . . . . . . . . 38
- 7.6.9.2 Delivery Times . . . . . . . . . . . . . . . 38
- 7.6.10 Billing Information . . . . . . . . . . . . . . . 39
- 7.6.11 Transparency . . . . . . . . . . . . . . . . . . . 39
- 7.6.12 RTS Password Management . . . . . . . . . . . . . 40
- 7.6.13 For Further Study . . . . . . . . . . . . . . . . 40
- 7.7 INTER and INTRA PRMD CONNECTIONS . . . . . . . . . . . . . . 40
- 7.7.1 Introduction . . . . . . . . . . . . . . . . . . . 40
- 7.7.2 The Relaying PRMD . . . . . . . . . . . . . . . . 41
- 7.7.2.1 Relay Responsibilities of a PRMD . . . . . . 41
- 7.7.2.2 Interaction with an ADMD . . . . . . . . . . 41
- 7.7.3 Intra PRMD Connections . . . . . . . . . . . . . . 42
- 7.7.3.1 Relay Responsibilities of an MTA . . . . . . 42
- 7.7.3.2 Loop Suppression within a PRMD . . . . . . . 43
- 7.7.3.3 Routing Within a PRMD . . . . . . . . . . . . 44
- 7.7.3.3.1 Class Designations . . . . . . . . . . . 44
- 7.7.3.3.2 Specification of MTA Classes . . . . . . 46
- 7.7.3.3.3 Consequences of Using Certain Classes of
- MTAs . . . . . . . . . . . . . . . . . . . . 46
- 7.7.3.4 Uniqueness of MPDUidentifiers Within a PRMD . 47
- 7.7.4 Service Elements and Optional User Facilities . . 47
- 7.7.5 X.400 Protocol Definitions . . . . . . . . . . . . 48
- 7.7.5.1 Protocol Classification . . . . . . . . . . . 48
- 7.7.5.2 P1 Protocol Elements . . . . . . . . . . . . 48
- 7.7.5.3 Reliable Transfer Server (RTS) . . . . . . . 51
- 7.8 ERROR HANDLING . . . . . . . . . . . . . . . . . . . . . . . 51
- 7.8.1 MPDU Encoding . . . . . . . . . . . . . . . . . . 52
- 7.8.2 Contents . . . . . . . . . . . . . . . . . . . . . 52
- 7.8.3 Envelope . . . . . . . . . . . . . . . . . . . . . 52
- 7.8.3.1 Pragmatic Constraint Violations . . . . . . . 52
- 7.8.3.2 Protocol Violations . . . . . . . . . . . . . 52
- 7.8.3.3 O/R Names . . . . . . . . . . . . . . . . . . 52
- 7.8.3.4 TraceInformation . . . . . . . . . . . . . . 53
- 7.8.3.5 InternalTraceInfo . . . . . . . . . . . . . . 54
- 7.8.3.6 Unsupported X.400 Protocol Elements . . . . . 54
- 7.8.3.6.1 deferredDelivery . . . . . . . . . . . . 54
- 7.8.3.6.2 PerDomainBilateralInfo . . . . . . . . . 55
- 7.8.3.6.3 ExplicitConversion . . . . . . . . . . . 55
- 7.8.3.6.4 alternateRecipientAllowed . . . . . . . 55
- 7.8.3.6.5 contentReturnRequest . . . . . . . . . . 55
- 7.8.3.7 Unexpected Values for INTEGER Protocol Elements 55
- 7.8.3.7.1 Priority . . . . . . . . . . . . . . . . 55
- 7.8.3.7.2 ExplicitConversion . . . . . . . . . . . 56
- 7.8.3.7.3 ContentType . . . . . . . . . . . . . . 56
- 7.8.3.8 Additional Elements . . . . . . . . . . . . . 56
- 7.8.4 Reports . . . . . . . . . . . . . . . . . . . . . 56
- 7.9 MHS USE OF DIRECTORY SERVICES . . . . . . . . . . . . . . . 56
- 7.9.1 Directory Service Elements . . . . . . . . . . . . 56
- 7.9.2 Use of Names and Addresses . . . . . . . . . . . . 57
- 7.10 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 58
- 7.10.1 Introduction . . . . . . . . . . . . . . . . . . . 58
- 7.10.2 Definition of Conformance . . . . . . . . . . . . 58
- 7.10.3 Conformance Requirements . . . . . . . . . . . . . 60
- 7.10.3.1 Introduction . . . . . . . . . . . . . . . . 60
- 7.10.3.2 Initial Conformance . . . . . . . . . . . . . 60
- 7.10.3.2.1 Interworking . . . . . . . . . . . 61
- 7.10.3.2.2 Service . . . . . . . . . . . . . . 61
- 7.11 APPENDIX A: INTERPRETATION OF X.400 SERVICE ELEMENTS . . 62
- 7.12 APPENDIX B: RECOMMENDED X.400 PRACTICES . . . . . . . . . 66
- 7.12.1 RECOMMENDED PRACTICES IN P2 . . . . . . . . . . . 66
- 7.12.2 RECOMMENDED PRACTICES IN RTS . . . . . . . . . . . 66
- 7.12.3 RECOMMENDED PRACTICES FOR ORName . . . . . . . . . 67
- 7.12.4 POSTAL ADDRESSING . . . . . . . . . . . . . . . . 70
- 7.12.5 EDI use of X.400 . . . . . . . . . . . . . . . . . 71
- 7.12.5.1 Introduction and Scope . . . . . . . . . . . 71
- 7.12.5.2 Model . . . . . . . . . . . . . . . . . . . . 71
- 7.12.5.3 Protocol Elements Supported for EDI . . . . . 73
- 7.12.5.4 Addressing and Routing . . . . . . . . . . . 73
- 7.12.6 USA Body Parts . . . . . . . . . . . . . . . . . . 74
- 7.13 APPENDIX C: RENDITION OF IA5Text AND T61String CHARACTERS 75
- 7.13.1 GENERATING AND IMAGING IA5Text . . . . . . . . . . 75
- 7.13.2 GENERATING AND IMAGING T61String . . . . . . . . . 75
- 7.14 APPENDIX D: DIFFERENCES IN INTERPRETATION DISCOVERED
- THROUGH TESTING OF THE MHS FOR THE CeBit 87
- DEMONSTRATION . . . . . . . . . . . . . . . . 76
- 7.14.1 ENCODING OF RTS USER DATA . . . . . . . . . . . . 76
- 7.14.2 EXTRA SESSION FUNCTIONAL UNITS . . . . . . . . . . 76
- 7.14.3 MIXED CASE IN THE MTA NAME . . . . . . . . . . . . 77
- 7.14.4 X.410 ACTIVITY IDENTIFIER . . . . . . . . . . . . 77
- 7.14.5 ENCODING OF PER RECIPIENT FLAG AND PER MESSAGE FLAG 77
- 7.14.6 ENCODING OF EMPTY BITSTRINGS . . . . . . . . . . . 78
- 7.14.7 ADDITIONAL OCTETS FOR BITSTRINGS . . . . . . . . . 78
- 7.14.8 APPLICATION PROTOCOL IDENTIFIER . . . . . . . . . 78
- 7.14.9 INITIAL SERIAL NUMBER IN S-CONNECT . . . . . . . . 78
- 7.14.10 CONNECTION DATA ON RTS RECOVERY . . . . . . . . . 78
- 7.14.11 ACTIVITY RESUME . . . . . . . . . . . . . . . . . 78
- 7.14.12 OLD ACTIVITY IDENTIFIER . . . . . . . . . . . . . 79
- 7.14.13 NEGOTIATION DOWN TO TRANSPORT CLASS 0 . . . . . . 79
- 7.15 APPENDIX E: WORLDWIDE X.400 CONFORMANCE PROFILE MATRIX . 80
- 7.16 APPENDIX F: INTERWORKING WARNINGS . . . . . . . . . . . . 91
-
-
- 8. DIRECTORY SERVICES PROTOCOLS . . . . . . . . . . . . . . . . . . 1
- 8.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
- 8.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 2
- 8.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 8.4 USE OF DIRECTORIES . . . . . . . . . . . . . . . . . . . . . 3
- 8.5 DIRECTORY ASEs, APPLICATION CONTEXTS, AND PORTS . . . . . . 4
- 8.6 SCHEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8.6.1 Maintenance of Structures and Naming Rules . . . . 5
- 8.6.2 Maintenance of object classes and subclasses . . . 6
- 8.6.3 Maintenance of Attribute Types . . . . . . . . . . 6
- 8.6.4 Maintenance of Attribute Syntaxes . . . . . . . . 6
- 8.7 CLASSIFICATION OF SUPPORT FOR ATTRIBUTE TYPES . . . . . . . 6
- 8.7.1 Mandatory Support . . . . . . . . . . . . . . . . 7
- 8.7.2 Optional Support . . . . . . . . . . . . . . . . . 7
- 8.8 INTORDUCTION TO PRAGMETIC CONSTRAINTS . . . . . . . . . . . 8
- 8.9 GENERAL CONSTRAINTS . . . . . . . . . . . . . . . . . . . . 8
- 8.9.1 Character Sets . . . . . . . . . . . . . . . . . . 8
- 8.9.2 APDU Size Considerations . . . . . . . . . . . . . 8
- 8.9.3 Service Control (SC) Considerations . . . . . . . 9
- 8.9.4 Priority Service Control . . . . . . . . . . . . . 9
- 8.10 CONSTRAINTS ON OPERATIONS . . . . . . . . . . . . . . . . . 10
- 8.10.1 Filters . . . . . . . . . . . . . . . . . . . . . 10
- 8.10.2 Errors . . . . . . . . . . . . . . . . . . . . . . 10
- 8.11 CONSTRAINTS ON ATTRIBUTE TYPES . . . . . . . . . . . . . . . 10
- 8.11.1 Attribute Values . . . . . . . . . . . . . . . . . 10
- 8.12 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 15
- 8.12.1 DUA Conformance . . . . . . . . . . . . . . . . . 15
- 8.12.2 DSA Conformance . . . . . . . . . . . . . . . . . 16
- 8.12.3 Directory Systems Conformance Classes . . . . . . 17
- 8.12.4 Authentication Conformance . . . . . . . . . . . . 17
- 8.12.5 Authentication Conformance Classes . . . . . . . . 18
- 8.13 DISTRIBUTED OPERATIONS . . . . . . . . . . . . . . . . . . . 18
- 8.13.1 Referrals and Chaining . . . . . . . . . . . . . . 19
- 8.14 UNDERLYING SERVICES . . . . . . . . . . . . . . . . . . . . 19
- 8.14.1 ROSE . . . . . . . . . . . . . . . . . . . . . . . 19
- 8.14.2 Session . . . . . . . . . . . . . . . . . . . . . 19
- 8.15 ACCESS CONTROL . . . . . . . . . . . . . . . . . . . . . . . 19
- 8.16 AUTHENTICATION . . . . . . . . . . . . . . . . . . . . . . . 19
- 8.17 TEST CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 20
- 8.17.1 Major elements of Architecture . . . . . . . . . . 20
- 8.17.2 Search Operation . . . . . . . . . . . . . . . . . 21
- 8.18 ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 8.18.1 Permanent vs. Temporary Service Errors . . . . . . 21
- 8.19 APPENDIX A Definitions . . . . . . . . . . . . . . . . . 22
- 8.20 APPENDIX B Attributes and Object Classes . . . . . . . . 23
- 8.21 APPENDIX C The Use of ROSE . . . . . . . . . . . . . . . 28
- 8.22 APPENDIX D Guidelines . . . . . . . . . . . . . . . . . 29
- 8.23 APPENDIX E Glossary . . . . . . . . . . . . . . . . . . 30
-
- 9. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 9.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 1
- 9.2 Matrix of Security Services and OSI Layers . . . . . . . . . 2
-
- 10. OBJECT IDENTIFIER: STRUCTURE AND ALLOCATION . . . . . . . . 1
- 10.1 Specific ASE Requirements for ACSE Presentation and Session 5
- 10.1.1 FTAM . . . . . . . . . . . . . . . . . . . . . . . 5
- 10.1.1.1 Phase 2 . . . . . . . . . . . . . . . . . . . 5
- 10.1.2 MHS . . . . . . . . . . . . . . . . . . . . . . . 8
- 10.1.2.1 Phase 1 . . . . . . . . . . . . . . . . . . . 8
- 10.1.3 DS . . . . . . . . . . . . . . . . . . . . . . . . 9
- 10.1.3.1 Phase 1 . . . . . . . . . . . . . . . . . . . 9
-
- 11. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 11.1 CCITT . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- 11.2 ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 11.3 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 11.4 NBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 11.5 MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 11.6 TOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 11.7 CEN/CENELEC . . . . . . . . . . . . . . . . . . . . . . . . 10
- 11.8 SPAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- List of Figures
-
- Figure 2.1 LSAP bit pattern . . . . . . . . . . . . . . . . . . . 1
- Figure 2.2 I-Field Format . . . . . . . . . . . . . . . . . . . . . 4
-
- Figure 4.1 AK exchange on idleconnection . . . . . . . . . . . . . 6
-
- Figure 6.1 Model of file transfer/access . . . . . . . . . . . . . 2
- Figure 7.1 The layered structure of this implementation agreement . 1
- Figure 7.2 This agreement applies to the interface between: (A) PRMD
- and PRMD; (B) PRMD and ADMD; (C) ADMD and ADMD; and (D)
- MTA and MTA . . . . . . . . . . . . . . . . . . . . . . . 3
- Figure 7.3 Interconnection of private domains . . . . . . . . . . . 4
- Figure 7.4 X.409 Definition of Privately Defined BodyParts . . . . 22
- Figure 7.5 An ADMD may (b) or may not (a) serve as a relay . . . . 33
- Figure 7.6 Relaying PRMD . . . . . . . . . . . . . . . . . . . . . 41
- Figure 7.7 Intra PRMD connections . . . . . . . . . . . . . . . . . 42
- Figure 7.8 MD C must know of A to route the message . . . . . . . . 42
- Figure 7.9 Definition of InternalTraceInfo . . . . . . . . . . . . 43
- Figure 7.10 Defined Actions in MTASuppliedInfo . . . . . . . . . . . 44
- Figure 7.11 Example of a confirguration to be avoided . . . . . . . 47
-
-
- Figure 8.1 Structure of this Implementation Agreement . . . . . . . 1
- Figure 8.2 Centralized Directory Model . . . . . . . . . . . . . . 2
- Figure 8.3 Distributed Directory Model . . . . . . . . . . . . . . 3
- Figure 8.4 Access to the Directory . . . . . . . . . . . . . . . . 5
- Figure 8.5 APDU Exchange . . . . . . . . . . . . . . . . . . . . . 8
- Figure 8.6 Logical DSA Application Environment . . . . . . . . . . 9
- List of Tables
-
- Table 5.1 Session States . . . . . . . . . . . . . . . . . . . . . 18
- Table 5.2 Incoming Events . . . . . . . . . . . . . . . . . . . . . 19
-
- Table 6.1 Parameters for FTAM-1, -2, -3 . . . . . . . . . . . . . . 8
- Table 6.2 Parameters for NBS-6, NBS-7, NBS-8 . . . . . . . . . . . 10
- Table 6.3 FTAM primitive data types . . . . . . . . . . . . . . . . 11
- Table 6.4 IRV Graphic Character Allocations . . . . . . . . . . . . 13
- Table 6.5 Interoperable configurations . . . . . . . . . . . . . . 21
- Table 6.6 Required minimal parameter support . . . . . . . . . . . 27
- Table 6.7 Implementation profile support requirements . . . . . . . 34
- Table 6.8 Implementation Profiles (NBS) and Profiles (SPAG/CEN-CLC) 38
- Table 6.9 Information objects in NBS-6 . . . . . . . . . . . . . . 41
- Table 6.10 Information objects in NBS-7 . . . . . . . . . . . . . . 46
- Table 6.11 Information objects in NBS-8 . . . . . . . . . . . . . . 50
- Table 6.12 Datatypes for keys . . . . . . . . . . . . . . . . . . . 52
- Table 6.12 Information objects in NBS-9 . . . . . . . . . . . . . . 56
- Table 6.14 Basic constraints for NBS Ordered flat . . . . . . . . . 60
- Table 6.15 Identity constraints in NBS Ordered flat . . . . . . . . 61
- Table 7.1 Basic MT service elements . . . . . . . . . . . . . . . 6
- Table 7.2 MT optional user facilities provided to the UA-selectable on
- a per-message basis . . . . . . . . . . . . . . . . . . . 7
- Table 7.3 MT optional user facilities provided to the UA agreed for
- any contractual period of time . . . . . . . . . . . . . . 7
- Table 7.4 Basic IPM service elements . . . . . . . . . . . . . . . 8
- Table 7.5 IPM optional facilities agreed for a contractual period of
- time . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- Table 7.6 IPM optional user facilities selectable on a per-message
- basis . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- Table 7.7 Protocol Classifications . . . . . . . . . . . . . . . . 10
- Table 7.8 P1 protocol elements . . . . . . . . . . . . . . . . . . 12
- Table 7.9 ORName protocol elements . . . . . . . . . . . . . . . . 17
- Table 7.10 P2 heading protocol elements . . . . . . . . . . . . . . 19
- Table 7.11 P2 BodyParts . . . . . . . . . . . . . . . . . . . . . . 23
- Table 7.12 Checkpoint window size of IP . . . . . . . . . . . . . . 29
- Table 7.13 RTS protocol elements . . . . . . . . . . . . . . . . . 30
- Table 7.14 P1 Protocol Classification Changes for a Delivering ADMD 34
- Table 7.15 Delivery Time Targets . . . . . . . . . . . . . . . . . 38
- Table 7.16 Forced Nondelivery Times . . . . . . . . . . . . . . . . 39
- Table 7.17 Conformant MTA Classifications . . . . . . . . . . . . . 45
- Table 7.18 P1 Protocol Elements . . . . . . . . . . . . . . . . . . 49
- Table 7B.1 Printable string to ASCII mapping . . . . . . . . . . . 69
- Table 7E.1 Protocol element comparison of RTS . . . . . . . . . . . 81
- Table 7E.2 Protocol element comparison of P1 . . . . . . . . . . . 83
- Table 7E.3 Protocol element comparison of P2 . . . . . . . . . . . 88
-
- Table 8.1 Pragmatic Constraints for Selected Attributes. . . . . . 12
-
- Table 9.1 OSI Layers Desirable for Placing Security . . . . . . . . 3
-
- 1. GENERAL INFORMATION
-
- 1.1 PURPOSE OF THIS DOCUMENT
-
- This document records stable implementation agreements of OSI
- protocols among the organizations participating in the NBS Workshop
- for Implementors of OSI. Stable in the context of this document
- means that:
-
- 1) The agreements are based on final standards
- (e.g., ISO-IS or CCITT Recommendations) or
- nearly final (e.g., ISO-DIS) with no
- significant changes expected, and,
-
- 2) The agreements have been approved by the NBS
- Workshop Plenary for progression from the "On-
- Going" agreements document to the draft stable
- agreements document and after a period of
- review have been passed to these final stable
- agreements. The only changes allowed will be
- clarifications, errata and the correction of
- omissions discovered in their implementation.
-
- For these reasons, the agreements are considered advanced enough for
- use in product and test suite development, as well as for procurement
- references.
-
- Future releases of these Stable Agreements will add and/or extend
- functionality offered by this version. When required, new versions
- will be introduced on a yearly basis. It is the NBS Workshop intent
- that new versions of this Stable Agreements document will be
- compatible with the present version. If this proves impractical, the
- agreements will attempt to provide mechanisms and guidelines which
- maximize interoperability.
-
-
- 1.2 PURPOSE OF THE WORKSHOP
-
- In February, 1983, at the request of industry, NBS organized the NBS
- Workshop for Implementors of OSI to bring together future users and
- potential suppliers of OSI protocols. The workshop accepts as input
- the specifications of emerging standards for protocols and produces as
- output agreements on the implementation and testing particulars of
- these protocols. This process is expected to expedite the development
- of OSI protocols and promote interoperability of independently
- manufactured data communications equipment.
-
- 1.3 WORKSHOP ORGANIZATION
-
- The Workshop organizes its work through Special Interest Groups
- (SIGs) that prepare technical documentation. An executive committee
- of SIG chairpersons led by the overall Workshop chairperson
- administers the workshop. NBS invites highly qualified technical
- leaders from participating organizations to assume leadership roles in
- the SIGs. The SIGs are encouraged to coordinate with standards
- organizations and user groups, and to seek widespread technical
- consensus on implementation agreements through international
- discussions and liaison activities.
-
- The Workshop meets four times a year at the National Bureau of
- Standards in Gaithersburg, Maryland where each SIG is required to
- convene its meeting. In addition, a plenary assembly of all workshop
- delegates is convened for consideration of SIG motions and other
- workshop business. SIGs are also encouraged to hold interim meetings
- at varied locations around the world.
-
- The Workshop is an open public forum. Registration materials,
- documents, and workshop schedules are available from:
-
-
- National Bureau of Standards
- NBS Workshop for Implementors of OSI
- Building 225, Room B-217
- Gaithersburg, Maryland 20899
- 2. SUB NETWORKS
-
- 2.1 INTRODUCTION
-
- This chapter provides agreements about subnetwork services used in
- providing the OSI Network Layer.
-
-
- 2.2 SCOPE AND FIELD OF APPLICATION
-
- These agreements cover subnetwork types including local area networks,
- packet switched networks, circuit switched networks, ISDN, and others.
-
-
- 2.3 STATUS
-
- This version was completed on December 18, 1987.
-
- Ongoing work for other agreements and for future versions of these
- agreements is contained in the "On-Going" agreements document,
- including provisions for ISDN.
-
-
- 2.4 ERRATA
-
-
- 2.5 LOCAL AREA NETWORKS
-
- 2.5.1 IEEE 802.2 LOGICAL LINK CONTROL
-
- The following decisions have been reached with respect to this
- protocol.
-
- l. Link Service Access Point (LSAP)
-
- The IEEE 802 committee has assigned the code below to
- address systems using any ISO network layer protocol. Note
- that bit zero is transmitted first.
-
- The most significant bit is bit 7, thus this bit pattern
- represents hexadecimal FE.
-
- 0 l 2 3 4 5 6 7
- ZDDDBDDDBDDDBDDDBDDDBDDDBDDDBDDD?
- 3 0 3 l 3 l 3 l 3 l 3 l 3 l 3 1 3
- @DDDADDDADDDADDDADDDADDDADDDADDDY
-
- Figure 2.1 LSAP bit pattern
-
-
- 2. Type and Class
-
- Only the connectionless type l, class l IEEE 802 link
- service will be used.
-
-
- 2.5.2 IEEE 802.3 CSMA/CD ACCESS METHOD
-
-
- The following implementation agreements have been reached with
- respect to the IEEE 802.3 CSMA/CD Access Method and Physical
- Layer Specifications: for 10 BASE 5:
-
- o The address length shall be 48 bits
-
-
- The following implementation agreements have been reached with
- respect to 10 BROAD 36 Networks:
-
- 1. Single Cable Networks
-
- - The translator frequency shall be 192.25 Mhz
- - The channel allocations are
-
- Reverse Channels Forward Channels
-
- T12, T13, T14 L, M, N
- T13, T14, 2' M, N, O
- T14, 2', 3' N, O, P
- 2', 3', 4' O, P, Q
- 3', 4', 4A' P, Q, R
- 4', 4A', 5' Q, R, S
-
- 2. Dual Cable Networks
-
- For nontranslated dual cable networks forward and
- reverse frequencies are the same. Permissible
- channel allocations are:
-
- T12, T13, T14
- T13, T14, 2'
- T14, 2', 3'
- 2', 3', 4'
- 3', 4', 4A'
- 4', 4A', 5'
- L, M, N
- M, N, O
- N, O, P
- O, P, Q
- Q, R, S
-
- 3. When both IEEE 802.4 and IEEE 802.3 10 BROAD 36
- networks coexist on the broadband cable system the
- preferred channel allocations are:
-
- Reverse Forward
-
- IEEE 802.3 T12, T13, T14 L, M, N
-
- IEEE 802.4 6', FM1' T, U
-
- channels 3', 4' P, Q
- reserved for 4A', 5' R, S
- future use
-
-
-
- 2.5.3 IEEE 802.4 TOKEN BUS ACCESS METHOD
-
- The following options are agreed to with respect to Draft J of
- token bus:
-
- o Data Rate:
-
- - 10 Mb (Broadband)
- - 5 Mb (carrierband)
-
- o Addressing: 48 bit
-
- o The lmeOption, Priority Mechanism, shall be implemented
-
- o Broadband Channel Assignments
-
-
- Forward Reverse
- P 3'
- Q 4'
- R 4A'
- S 5'
- T 6'
- U FM1'
-
-
- 2.5.4 IEEE 802.5 TOKEN RING ACCESS METHOD
-
- The following implementation agreements have been reached with
- respect to the IEEE Standard 802.5, Token Passing Ring Access
- Method and Physical Layer specification.
-
- o The data signalling rate shall be 4 Mbit/s
-
- o The address length shall be 48 bits
-
- o The message priority (PM) of the AMP data unit shall be
- 7
-
- o The ALL_STATIONS_THIS_RING_ADDRESS shall be
- X'COOOFFFFFFFF'
-
- o The TRR value shall be 4 milliseconds
-
- o The THT value shall be 8.9 milliseconds
-
- o The TQP value shall be 20 milliseconds
-
- o The TVX value shall be 10 milliseconds
-
- o The TNT value shall be 2.6 milliseconds
-
- o The TAM value shall be 7 seconds
-
- o The TSM value shall be 15 seconds
-
- o The MAC Information field (I-field) shall be defined as
- follows:
-
- ZDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDD?
- 3 Starting Sequence 3 I-Field 3 End Sequence 3
- @DDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDY
-
- and the:
-
- 1) Starting Sequence includes: SD, AC, FC, DA, SA
- 2) Ending Sequence includes: FCS, ED, FS
-
-
- Figure 2.2 I-Field Format
-
-
- o With the above timer and MAC I-field definitions, the
- following limits are defined:
-
- - Protocol limits the I-field to a maximum of 4425
- bytes.
-
- - All stations shall support I-fields that have a
- minimum of one byte and a maximum of at least 2000
- bytes.
-
-
- 2.6 WIDE AREA NETWORKS
-
-
- 2.6.1 CCITT RECOMMENDATION X.25
-
- The procedures required to describe the DTE/DTE interface and the
- DTE side of the DTE/DCE interface, for systems attached to
- subnetworks providing an X.25 interface shall be as defined in
- ISO 7776 and ISO 8208.
- 3. NETWORK LAYER
-
-
- 3.1 INTRODUCTION
-
- This chapter presents agreements for providing the OSI network
- service. Also contained here are agreements on network layer
- addressing and routing.
-
-
- 3.2 SCOPE AND FIELD OF APPLICATION
-
- These agreements cover both connectionless-mode and connection-mode
- network services.
-
-
- 3.3 STATUS
-
- This version of the agreements was completed on December 18, 1987.
-
- Ongoing work for other agreements and for future versions of these
- agreements is contained in the "On-Going" agreements document,
- including provisions for ISDN, and including specific aspects of using
- the X.25 PLP over LANs.
-
-
- 3.4 ERRATA
-
-
- 3.5 CONNECTIONLESS-MODE NETWORK SERVICE (CLNS)
-
-
- 3.5.1 Provision of CLNS over Local Area Networks (LANS)
-
- When providing CLNS over a LAN subnetwork, the following shall
- apply:
-
- 1. The definition of CLNS shall be as specified in ISO
- 8348/AD1.
-
- 2. The protocol used to provide CLNS shall be ISO 8473
- with agreements as specified in 3.5.3.1.
-
-
- 3.5.2 Provision of CLNS over X.25 Subnetworks
-
- When providing CLNS over X.25 subnetworks, the following shall
- apply:
-
- 1. The definition of CLNS shall be as specified in ISO
- 8348/AD1.
-
- 2. The protocol used to provide CLNS shall be ISO 8473
- with agreements as specified in 3.5.3.1.
-
- 3. The necessary subnetwork dependant convergence function
- shall be as defined in ISO 8473 for operation over X.25
- subnetworks, with agreements as specified in 3.5.3.2.
-
- 4. The X.25 PLP shall be as defined in ISO 8208.
-
-
-
- 3.5.3 Agreements on Protocols
-
-
- 3.5.3.1 ISO 8473
-
- 1. Subsets of the protocol:
-
- o Implementations will not transmit PDUs encoded
- using the inactive subset. Received PDUs encoded
- using the inactive subset will be discarded.
-
- o The non-segmenting subset will not be used.
- Implementations will not generate data PDUs
- without a segmentation part. However,
- implementations will receive and correctly process
- PDUs which do not contain the segmentation part.
-
- 2. Mandatory Functions:
-
- o The lifetime parameter shall be used as specified
- in section 6.4 of ISO 8473. The parameter shall
- have an initial value of at least three times the
- network span or three times the maximum transit
- delay (in units of 500 milliseconds), whichever is
- greater.
-
- o The reassembly timer for an initial PDU at the
- reassembly point shall be no greater than the
- largest value of all lifetime parameters contained
- in all derived PDUs.
-
- 3. Optional Functions:
-
- o The Security parameter is not defined by these
- Agreements. Implementations shall not transmit
- the parameter except where defined by bilateral
- agreements.
-
- o Partial and complete source Routing will not be
- supported.
-
- o Partial record of Route will be supported by
- Intermediate systems.
-
- o ISO 8473 will be followed with respect to QOS.
-
-
- 3.5.3.2 Subnetwork Dependent Convergence Function
-
- 1. When 8473 SNDC functions are used over X.25
- subnetworks, the default throughput class shall be used
- if this facility is available.
-
-
- 3.6 CONNECTION-MODE NETWORK SERVICE (CONS)
-
- The following agreements concern provision of the connection-mode
- Network Service.
-
-
- 3.6.1 Mandatory Method of Providing CONS
-
- When providing CONS using X.25 1984, the following shall apply:
-
- o The definition of the CONS is as specified in ISO 8348,
- Network Service Definition.
-
- o The mapping of the elements of the CONS to the elements of
- the X.25 Packet Level Protocol (PLP) is as specified in ISO
- 8878, Use of X.25 to Provide the Connection-mode Network
- Service.
-
- o The general procedures and formats of the X.25 PLP are as
- specified in ISO 8208, X.25 Packet Level Protocol for Data
- Terminal Equipment.
-
-
- 3.6.2 Additional Option: Provision of CONS over X.25 1980
- Subnetworks
-
- When providing CONS over an X.25 1980 subnetwork, the following
- shall apply:
-
- o The definition of the CONS is as specified in ISO 8348,
- Network Service Definition.
-
- o The subnetwork dependant convergence protocol required
- to provide CONS shall be as specified in ISO 8878 Annex
- A, and referred to as the Alternative Procedures for
- Network Connection Establishment and Release, with
- agreements as defined in 3.6.3.2.
-
-
- 3.6.3 Agreements on Protocols
-
-
- 3.6.3.1 ISO 8878
-
- o The Receipt Confirmation service will not be provided,
- so the corresponding protocol elements need not be
- implemented.
-
- o The Expedited Data service will not be provided, so the
- corresponding protocol elements need not be
- implemented.
-
- o Where the ISO 8208 diagnostic codes are not provided,
- all Cause/Diagnostic code combinations can be mapped
- to the Originator/Reason code of "Undefined".
-
-
- 3.6.3.2 Subnetwork Dependent Convergence Protocol (ISO
- 8878/Annex A)
-
- o The Receipt Confirmation service will not be provided,
- so the corresponding protocol elements need not be
- implemented.
-
- o The Expedited Data service will not be provided, so the
- corresponding protocol elements need not be
- implemented.
-
- 3.7 ADDRESSING
-
- Address formats supported will conform to ISO 8348 DAD2.
-
- o NSAP address formats will have a hierarchical structure.
- This will reduce the size of routing tables.
-
- o If used in the Domain Specific Part (DSP), an NSAP selector
- shall be the least significant component in the hierarchy.
- The NSAP selector shall not be used to preform routing; it
- is simply intended to identify the network service user at
- the destination end system. For those implementations
- using an NSAP selector, there shall be one and only one
- selector for each NSAP within the end system. All NSAP
- addresses identifying a given NSAP will use the same NSAP
- selector value.
-
-
- 3.8 ROUTING
-
-
- 3.8.1 Static Routing
-
- End systems and intermediate systems supporting static routing
- will provide a local mechanism to update and, if necessary, to
- create the local routing table. Updating and consistency
- checking will be performed by human operators. The algorithms
- and data structures used for static routing are not specified in
- these agreements. Implementors are free to perform these
- functions in the manner which is most appropriate to their system
- environment.
-
-
- 3.8.2 End System to Intermediate System
-
- Dynamic routing between end systems and intermediate systems is
- performed using the protocol described in ISO 9542, End System to
- Intermediate System Routing Exchange Protocol for use in
- conjunction with ISO 8473. The following agreements apply to the
- use of this protocol over LANs and point-to-point links.
-
- 1. Implementations must support any valid NSAP format. For
- the purposes of the protocol, NSAP addresses are
- treated simply as octet strings.
-
- 2. Implementations must support both Configuration
- Information and Route Redirection Information. No
- subsets are permitted.
-
- 3. All timer values must be settable using local system
- management.
-
- 4. Use of checksums must be settable using local system
- management. Under normal use, checksums will be
- disabled.
-
- 5. The QOS, Security and Priority parameters should not be
- used for routing. For conformance, Intermediate
- systems must transmit these parameters in RD PDUs if
- they are present in the data PDU which generated the
- redirect. However, End systems must ignore them in
- received RD PDUs.
-
- 6. Both ES and IS implementations must support the
- 'optimization' described in Clause A.3 of ISO 9542 for
- system initialization. Its use must be selectable
- using local system management.
-
- 7. This protocol employs the same LSAP as ISO 8473.
-
- 8. The encoding of the BSNPA address follows the syntax
- rules for the data link being used. On a LAN, for
- example, it is a 48-bit MAC address.
-
- 9. The multicast addresses corresponding to "All
- Intermediate Systems on the network" (All_ISN) and "All
- End Systems on the network" (All_ESN) shall default to
- the following:
-
- All_ISN = 0900 2B00 0004
- All_ESN = 0900 2B00 0005
-
- 10. The ES-IS protocol should be primarily responsible for
- updating the Network Layer Routing Information Base
- (RIB). In addition, a management mechanism capable of
- adding and deleting "static" entries into the RIB is
- recommended. When using the management mechanism to
- add an entry, there should be no holding timer, and the
- entry should be write protected from alteration by the
- ES-IS protocol.
-
- Note: This function enables route table entries to be
- made which are static in nature. The use of
- static entries is not intended for normal
- operations, but rather is provided for test and
- debug as well as for interoperation with other OSI
- implementations which do not support the ES-IS
- protocol.
-
-
- 3.9 MIGRATION CONSIDERATIONS
-
- This section considers problems arising from evolving OSI standards
- and implementations based on earlier versions of OSI standards.
-
-
- 3.9.1 X.25-1980
-
- Until there is widespread availability of 1984 X.25 service, it
- will be necessary for X.400 systems to use those existing packet-
- switched public data networks which offer only pre-1984 X.25
- service. While 1980 X.25 does not provide the CONS as defined by
- ISO 8348, there is no implication of non-conformance to these
- Agreements resulting there from for systems using 1980 X.25 to
- interchange data at the Network Layer, provided they conform in
- all other respects.
-
- This is an exception to the Agreements for providing the OSI
- Network Service, granted temporarily for practical reasons. This
- exception will be removed when it is deemed to be no longer
- necessary, in the judgement of the Workshop. While this
- provision is in effect, it provides an alternative method of
- using 1980 X.25 to the provisions of 3.6.2
-
- 3.10 CONFORMANCE
-
- 4. TRANSPORT
-
- 4.1 INTRODUCTION
-
- These agreements support the integration of LANs, packet networks, and
- other WANs with the smallest possible set of mandatory protocol sets,
- in accordance with the other agreements already reached. Nothing here
- shall preclude vendors from implementing protocol suites in addition
- to the ones described in this document.
-
- 4.2 SCOPE AND FIELD OF APPLICATION
-
- Two connection-oriented transport classed have been identified for
- implementation: classes 0 and 4. Transport class 4 is endorsed for
- use over CLNS and CONS. Transport class 0 is endorsed for use over
- CONS.
-
- 4.3 STATUS
-
- Completed March 1987.
-
- 4.4 ERRATA
-
- 4.5 TRANSPORT CLASS 4
-
- 4.5.1 Transport Class 4 Overview
-
- Transport class 4 is mandatory for communication between systems
- using the OSI CLNS and may also be used for systems using the OSI
- CONS (i.e., a private MHS, etc.).
-
- 4.5.2 Protocol Agreements
-
- The full protocol will be available including expedited data and
- negotiation at connection establishment. A disconnect request
- shall be issued in response to a connect request when the maximum
- number of transport connections is reached or exceeded.
-
- 4.5.2.1 Rules for Negotiation
-
- o In general, the ISO rules for negotiation will be used,
- specifics follow.
-
- o All implementations will send the l6/3l window
- size/sequence space in the CR TPDU. Implementations
- must all provide the l6/3l ISO option. Implementations
- must be able to accept the 4/7 in a CR TPDU.
-
- o The ISO maximum TPDU size is negotiable between l28 and
- 8K octets, always negotiated downward. The ISO rules
- are to be followed, allowing any valid size in the CR
- TPDU. TPDU size negotiation is a local implementation
- issue. Each vendor will decide how it is implemented
- in their end system.
-
- o The security parameter is optional and user defined in
- the ISO specification. Implementations should not send
- the security parameter in the CR TPDU; if received the
- parameter should be ignored.
-
- o The use of checksums shall be as specified in ISO 8073
- section 6.5.4., i.e., checksum shall be used unless
- both transports explicitly agree negotiate to its non-
- use. Requesting its non-use is an implementation
- choice. All implementations must be able to operate
- with checksums.
-
-
- o Use of acknowledgement time parameter is optional in
- ISO 8073. If an implementation is operating any policy
- which delays the transmission of AK TPDUs, the maximum
- amount of time by which a single AK TPDU may be delayed
- shall be indicated to the peer transport service
- provider using the acknowledgement time parameter. The
- value transmitted should be expressed in units of
- milliseconds and rounded up to the nearest whole
- millisecond.
-
- o Throughput, priority, and transit delay are optional in
- the ISO specification. Do not send in the CR TPDU;
- ignore in the CC TPDU.
-
- o User data in the CR TPDU and the CC TPDU are optional.
- No implementation should send; all implementations must
- be prepared to receive.
-
- o An unknown parameter in any received CR TPDU shall be
- ignored.
-
- o Known parameters with invalid values in a CR TPDU shall
- be handled as follows:
-
- Parameter Action
-
- TSAP id Send DR TPDU
- TPDU size ignore parm, use default
- Version ignore parm, usedefault
- Protection (Security) implementation dependent
- Checksum discard CR TPDU
- Additional Options Protocol Error
- Alternate Protocol Classes Protocol Error
- Acknowledge Time ignore parm
- Throughput ignore parm
- Residual Error Rate ignore parm
- Priority ignore parm
- Transit Delay ignore parm
-
-
- 4.5.2.2 TRANSPORT CLASS 4 SERVICE ACCESS POINTS OR
- SELECTORS
-
- The TSAP selector field in the CR and CC TPDUs shall be
- encoded as a variable length field and will be interpreted
- as an octet string. The length of the string cannot exceed
- 32 octets.
-
-
- 4.5.2.3 Retransmission Timer
-
- It is recommended that the value used for the retransmission
- timer be based upon the round-trip delay experienced on a
- transport connection. The implementation should maintain,
- and continually update, an estimate of the round-trip delay
- for the TC. From this estimate, a value for the
- retransmission timer is calculated each time it is started.
- An example technique for maintaining the estimate and
- calculating the retransmission timer is described below.
- The value of the retransmission timer may be calculated
- according to the following formula:
-
- tT1 <DDD kE + AR
-
- In this formula, E is the current estimate of the round-trip
- delay on the transport connection, AR is the value of the
- acknowledgement time parameter received from the remote
- transport service provider during connection establishment,
- and k is some locally administered factor.
-
- A value for k should be chosen to keep the retransmission
- timer sufficiently small such that lost TPDUs will be
- detected quickly, but not so small that false alarms are
- generated causing unnecessary retransmission.
-
- The value of E may be calculated using an exponentially
- weighted average based upon regular sampling of the interval
- between transmitting a TPDU and receiving the corresponding
- acknowledgement. Samples are taken by recording the time of
- day when a TPDU requiring acknowledgement is transmitted and
- calculating the difference between this and the time of day
- when the corresponding acknowledgement is received. New
- samples are incorporated with the existing average according
- to the following formula.
-
- E <DDD E + (1 - `)(S - E)
-
- In this formula, S is the new sample and ` is a parameter
- which can be set to some value between 0 and 1. The value
- chosen for ` determines the relative weighting placed upon
- the current estimate and the new sample. A large value of `
- weights the old estimate more heavily causing it to respond
- only slowly to variations in the round-trip delay.
-
- A small value weights the new sample more heavily causing a
- quick response to variations. (Note that setting ` to 1 will
- effectively disable the algorithm and result in a constant
- value for E, being that of the initial seed.)
-
- If ` is set to 1-2-n for some value of n, the update can be
- reduced to a subtract and shift as shown below.
-
- E <DDD E + 2-n (S - E)
-
- When sampling, if an AK TPDU is received which acknowledges
- multiple DT TPDUs, only a single sample should be taken
- being the round-trip delay experienced by the most recently
- transmitted DT TPDU. This attempts to minimize in the
- sample any delay caused by the remote transport service
- provider withholding AK TPDUs.
-
-
- 4.5.2.4 Keep-Alive Function
-
- The Class 4 protocol detects a failed transport connection
- by use of an 'inactivity timer'. This timer is reset each
- time a TPDU is received on a connection. If the timer ever
- expires, the connection is terminated.
-
- The Class 4 protocol maintains an idle connection by
- periodically transmitting an AK TPDU upon expiration of the
- 'window timer'. Thus, in a simple implementation, the
- interval of one transport entity's window timer must be less
- than that of its peer's inactivity timer, and vice versa.
- The following agreements permit communicating transport
- entities to maintain an idle connection without shared
- information about timer values.
-
- o In accordance with ISO 8073, clause 12.2.3.9.a,
- all implementations must respond to the receipt
- of a duplicate AK TPDU not containing FCC by
- transmitting an AK TPDU containing the 'flow
- control confirmation' parameter.
-
-
- o Implementations must always transmit duplicate AK
- TPDUs without FCC on expiration of the local
- window timer (see ISO 8073, clause 12.2.3.8.1).
- Receipt of this TPDU by the remote transport
- entity will cause it to respond with an AK TPDU
- containing the 'flow control confirmation'
- parameter. When this is received by the local
- transport entity, it will reset its inactivity
- timer. See figure 4.1.
-
- o It is a local matter for an implementation to set
- the intervals of its timers to appropriate
- relative values. Specifically:
-
- o The window timer must be greater than the
- round-trip delay. See section 4.1.4.
-
- o The inactivity timer must be greater than two
- times the window timer; and should normally be an
- even greater multiple if the transport connection
- is to be resilient to the loss of an AK TPDU.
-
- A duplicate AK TPDU (See Figure 4.1) is one which contains
- the same values for YR-TU-NR, credit, and subsequence number
- as the previous AK TPDU transmitted. A duplicate AK TPDU
- does not acknowledge any new data, nor does it change the
- credit window.
-
-
- I W
- 3 3 3 3
- 3 3 3 3
- 3 DDDDEDDDD 3 duplicate 3
- 3 expire 3 3 AK 3
- 3 3 3 3
- DDDDEDDDD 3 3 AK + FCC 3
- reset 3 3 3 3
- 3 3 3 3
- 3 3 3 3
- 3 DDDDEDDDD 3 duplicate 3
- 3 expire 3 3 AK 3
- 3 3 3 3
- 3 3 3 3
- DDDDEDDDD 3 3 AK + FCC 3
- reset 3 3 3 3
- 3 3 3 3
- 3 3 3 3
- 3 DDDDEDDDD 3 3
- 3 expire 3 3 3
- 3 3 3 3
- 3 3 3 3
-
-
- Figure 4.1 AK exchange on idleconnection
-
-
- 4.6 TRANSPORT CLASS 0
-
- 4.6.1 Transport Class 0 Overview
-
- Transport class 0 over X.25 is mandatory (see X.400) for use in
- communicating with public MHS systems operating in accordance
- with the CCITT X.400 series recommendations. The purpose of the
- agreements concerning transport class 0 is to allow connection to
- these public services. Transport class 0 over X.25 can also be
- used in communicating between PRMDs (this choice is prevalent
- outside North America).
-
- 4.6.2 Protocol Agreements
-
- Transport Class 0 agreements follow:
-
- o The Error (ER) TPDU may be used at any time and upon
- receipt requires that the recipient disconnect the
- network connection, and by extension the transport
- connection.
-
- o The allowed values for the maximum TPDU size are as
- specified in ISO 8073. They are: 128, 256, 512, 1024,
- and 2048.
-
- o The class 0 protocol does not support multiplexing. At
- any instant, one transport corresponds to one network
- connection.
-
- o It is recommended that the optional timers TS1 and TS2,
- if implemented, be settable by local system management.
- Values in the order of minutes should be supported.
-
- o An unlimited TSDU length must be supported.
-
-
- 4.6.2.1 TRANSPORT CLASS 0 SERVICE ACCESS POINTS
-
- For communicating with public MHS systems, Section 5 of
- X.410 specifies the use and format of TSAP identifiers.
-
- 4.6.3 Rules for Negotiation
-
- The ISO rules for negotiations will be used.
- 5. UPPER LAYERS
-
-
- 5.1 INTRODUCTION
-
- In this portion of the Implementors' Agreements, the NBS Upper Layers
- SIG is primarily concerned with providing implementation agreements
- for ACSE, and the Presentation and Session layers, so that systems
- implemented according to these agreements can successfully
- interoperate.
-
-
- 5.1.1 References
-
- All documents referenced in the Upper Layers section of these
- agreements can be found in the REFERENCES section of this NBS
- Implementors' Agreements document.
-
-
-
- 5.2 SCOPE AND FIELD OF APPLICATION
-
- This section does not detail particular conformance statements for
- ACSE, Presentation, and Session, since what is to be implemented in
- each case depends on which Application Service Elements (ASE's) and
- which functional units within each ASE are used with an Application
- Process. Each ASE's SIG must specify which functional units of each
- layer it requires. However, the scope of each layer is based on the
- total indicated requirements of all ASE's for which there is an active
- NBS SIG. The implementation agreements are not specified beyond that
- scope.
-
- It is not the intent of this document to specify or reproduce
- standards, but when a referenced standard is unclear or has known
- defects, an attempt will be made to remedy the problem herein. Any
- attempted clarification should be considered as a possible
- interpretation; the ISO standard still takes precedence if there is
- any conflict. The situation with respect to defects in a standard is
- somewhat different; a reported defect may be technically resolved by
- the appropriate international technical committee with likely approval
- by the voting members pending for several months. Since relevant
- defects can't be ignored in an implementation, this document will
- recommend using defect resolutions which have the tentative approval
- of the appropriate standards committees.
-
- 5.3 STATUS
-
- This document is the first stable version of the NBS UL SIG.
-
-
- 5.4 ERRATA
-
-
- 5.4.1 ISO Defect Reports
-
- This section lists the defect reports from ISO which are
- currently recognized to be valid for the purposes of NBS
- conformance.
-
-
- 5.4.2 Session Defects
-
- These defects are listed for the benefit of X.400
- implementations.
-
- The following 8326 defect reports have been incorporated into
- version 1 of Session:
-
- 004, 006, 007, 009, 011, 012, 013, 014, 015, 016, 017, 020.
-
- The following 8327 defect reports have been incorporated into
- version 1 of Session:
-
- 001, 003, 004, 005, 006, 007, 008, 009, 010, 012, 017, 018,
- 019, 026, 027, 030, 034, 035.
-
-
-
- 5.5 ASSOCIATION CONTROL SERVICE ELEMENT
-
-
- 5.5.1 Introduction
-
- This section details the implementation requirements for the
- Association Control Service Element (ACSE) of the Application
- layer. It is the intent of this section to follow the ISO ACSE
- standards. Where those specifications are inadequate, this
- section should provide the necessary information.
-
-
- 5.5.2 Services
-
-
- 5.5.2.1 ACSE Services
-
- The following ACSE service primitives are within the
- possible scope of an NBS conformant system:
-
- 1. A_ASSOCIATE request
- 2. A_ASSOCIATE indication
- 3. A_ASSOCIATE response
- 4. A_ASSOCIATE confirm
- 5. A_RELEASE request
- 6. A_RELEASE indication
- 7. A_RELEASE response
- 8. A_RELEASE confirm
- 9. A_ABORT request
- 10. A_ABORT indication
- 11. A_P_ABORT indication
-
-
- 5.5.2.2 Use of Presentation Layer Services
-
- ACSE services will make use of Presentation layer services
- in the manner defined in the ACSE Protocol specification.
-
-
- 5.5.3 Protocol agreements
-
- Implementations shall be based on the ACSE Service definition and
- the ACSE Protocol specification.
-
-
- 5.5.3.1 Application Context
-
- Specific Application Contexts and their names will be
- supplied and defined by an appropriate NBS SIG. Other
- application contexts may be defined and specified as
- dictated by particular application requirements.
-
- Optional names and specifications are outlined by each
- application SIG under the heading "Specific ASE
- Requirements for ACSE, Presentation, and Session". The use
- of these names implies adherence to the relevant NBS
- implementors' agreements for a particular application SIG.
-
- The utility of an NBS defined name (which is an OBJECT
- IDENTIFIER) is left up to the application. An NBS name may
- or may not be used in the ACSE APDU. The consequence of the
- name is left up to the application entities and any a priori
- agreements that they have. In other words, it is up to the
- application whether this parameter is ignored or validated
- for correctness. (Note that the consequence of this name
- must also be dictated by the particular conformance test).
-
- The UL SIG recognizes that this parameter needs further
- definition by the appropriate standards bodies. Therefore,
- the use of this parameter for association negotiation is not
- recommended at this time.
-
-
- 5.5.3.2 Section Deleted
-
-
- 5.5.3.3 AE Title
-
- A value is defined for the AE Title only to satisfy the FTAM
- requirement for exchanging fields of this type.
-
- This value does not identify an Application Entity and
- carries no semantics. The AE title maps onto the AP title
- and the AE qualifier. If the AE title is used, then both QP
- title (an OBJECT IDENTIFIER) and AE qualifier (an INTEGER)
- must be sent.
-
- The value for the AP titles is {1 3 999 1 ftam-nil-ap-title
- (7)} at this time. Values for the AE qualifier are outside
- the scope of these agreements.
-
-
- 5.6 PRESENTATION
-
-
- 5.6.1 Introduction
-
- This section details the implementation requirements for the
- Presentation layer. It is the intent of this section to follow
- the ISO Presentation Standards. Where those specifications are
- inadequate, this section should provide the necessary
- information.
-
- The task of the Presentation layer is to carry out the
- negotiation of transfer syntaxes and to provide for the
- transformation to and from transfer syntaxes. The transformation
- to and from a particular transfer syntax is a local
- implementation issue and is not discussed within this section.
- This section is concerned with the protocol agreements, and thus
- is entirely devoted to the issues involved with the negotiation
- of transfer syntaxes and the responsibilities of the
- Presentation protocol.
-
-
- 5.6.2 Services
-
-
- 5.6.2.1 Presentation Services
-
- The following functional units are within the possible scope
- of an NBS conformant system:
-
- Presentation Kernel - This functional
- unit supports the basic Presentation
- services required to establish a
- Presentation connection, transfer
- normal data, and release a
- Presentation connection. This is a
- non-negotiable functional unit.
-
- The Context Management and Context
- Restoration functional units are not
- within the scope of an NBS
- conformant system and need not be
- supported.
-
- The requirement that the Presentation kernel functional unit
- be implemented does not imply that any of the Session
- functional units for expedited data, typed data, and
- capability data and the corresponding Presentation service
- primitives are required to be implemented. Any service not
- supported by the Session layer is also not supported by the
- Presentation layer; see the section on Session Functional
- Units for the possible Session functional units. The
- services provided by the Presentation layer are limited by
- the services provided by the Session layer as defined in the
- Session service definition ISO/IS 8326 and the Session
- protocol definition ISO/IS 8327.
-
-
- 5.6.2.2 Use of Session Layer Services
-
- Presentation layer services shall make use of Session layer
- services in the manner defined in the Presentation Protocol
- Specification.
-
-
- 5.6.3 Protocol Agreements
-
- Implementations shall be based on the Presentation Service
- Definition, ISO 8822 and the Presentation Protocol Definition,
- ISO 8823.
-
-
- 5.6.3.1 Transfer Syntaxes
-
- o The following transfer syntax must be supported
- for all mandatory abstract syntaxes: the basic
- encoding rules for ASN.1. This syntax is derived
- by applying the basic encoding rules for ASN.1 to
- the abstract syntax (see the Basic Encoding Rules
- for ASN.1, ISO 8825).
-
- o The number of transfer syntaxes proposed is
- dependent upon the recognized transfer syntaxes
- which are available to support the particular
- abstract syntaxes used by an Application Entity.
-
-
- 5.6.3.2 Abstract Syntaxes
-
- o Several abstract syntax names may map onto a
- single transfer syntax name.
-
- o The ACSE abstract syntax shall always be present
- in the defined context set.
-
-
-
- 5.6.3.3 Presentation Context Identifier
-
- o The presentation context identifier value shall be
- encoded in no more than 2 octets.
-
- o Implementations must be able to handle a minimum
- of 2 presentation contexts per connection.
-
-
- 5.6.3.4 Mode-selector Position in SET
-
- Whenever the Mode-selector value within either a CP-PPDU or
- CPA-PPDU is normal-mode (1), it shall occur as the first
- element within the SET.
-
-
-
- 5.6.3.5 Default Context
-
- If the Presentation expedited data service is required, the
- default context must be explicitly present in the P-CONNECT
- PPDU at Presentation connect time.
-
-
- 5.6.3.6 P-Selectors
-
- Local P-selectors shall be a maximum of 4 octets. This
- applies only to P-selectors in PPDUs whose receipt by an
- NBS-conformant system normally results in either a P-CONNECT
- indication or a P-CONNECT confirmation being issued.
-
-
- 5.6.3.7 Provider Abort Parameters
-
- No conformance requirements are implied by the use of either
- the Abort-reason or the Event-identifier component of the
- ARP-PPDU. The decision to include these parameters is left
- up to the implementation issuing the abort.
-
-
- 5.6.3.8 Provider Aborts and Session Version
-
- The Presentation Provider Abort PPDU (ARP-PPDU) shall be
- present regardless of the Session version in effect for a
- given association. This precludes the use of indefinite
- length encoding of an ARP-PPDU when Session version 1 is in
- effect.
-
-
- 5.6.3.9 CPC-type
-
- NBS conformant implementations shall not use any CPC-type
- values in the SS-user data parameter of the S-CONNECT
- request unless more than one transfer syntax is proposed.
- Each CPC-type represents a unique transfer syntax. Note:
- currently only 1 transfer syntax is recognized.
-
-
- 5.6.3.10 Presentation-context-definition-result-list
-
- No semantics are implied by the absence of this optional
- component of the CPR-PPDU. This component is required if
- the Provider-reason is absent in the CPR-PPDU. If the
- Provider-reason is present, then the Presentation-context-
- definition-result-list is optional.
-
-
- 5.6.3.11 RS-PPDU
-
- The Presentation-context-identifier-list shall not be
- present when only the kernel functional unit is in effect.
-
-
- 5.6.4 Presentation ASN.1 Encoding Rules
-
-
- 5.6.4.1 Invalid Encoding
-
- If a received PPDU contains any improperly encoded data
- values (including data values embedded within the User Data
- field of a PPDU) and an abort is issued, then either a P-U-
- ABORT or a P-P-ABORT shall be issued.
-
-
- 5.6.4.2 Protocol-version, Presentation-requirements
-
- Protocol-version and Presentation-requirements shall be
- encoded in their primitive forms, if present.
-
-
- 5.6.4.3 Presentation-selector
-
- Any type defined as a Presentation-selector shall be encoded
- in its primitive form, if present.
-
-
-
- 5.7 SESSION
-
-
- 5.7.1 Introduction
-
- This section details the implementation requirements for the
- Session layer. It is the intent of this section to follow the
- ISO Session Standards to the fullest extent possible. Where
- those specifications are inadequate, this section should provide
- the necessary information.
-
-
- 5.7.2 Services
-
-
- 5.7.2.1 Session Services
-
- The following functional units are within the possible scope
- of an NBS conformant system:
-
- Kernel
-
- Duplex
-
- Expedited Data
-
- Resynchronize
-
- Exceptions
-
- Activity Management
-
- Half-duplex
-
- Minor Synchronize
-
- Major Synchronize
-
- Typed Data
-
-
- 5.7.2.2 Use of Transport Services
-
- The use of Transport layer services by the Session layer
- functional units listed in the previous section is as
- specified in the Transport Protocol Specification, ISO/IS
- 8073.
-
-
- 5.7.3 Protocol Agreements
-
- Implementations shall be based on the Session service definition
- ISO/IS 8326 and the Session protocol definition ISO/IS 8327.
-
-
- 5.7.3.1 Concatenation
-
- When a category 0 SPDU is concatenated with a category 2
- SPDU, the category 0 SPDU shall contain neither the Token
- Item field nor User Data. If either a Token Item field or
- User Data is received in such a concatenated incoming SPDU,
- the receiving Session Protocol Machine has the option of
- either properly processing the fields or issuing a provider
- abort on the connection.
-
- Extended concatenation is not required and can be refused
- using the normal negotiation mechanisms of the Session
- protocol.
-
-
- 5.7.3.2 Segmenting
-
- Session Segmenting is not required and can be refused using
- the normal negotiation mechanisms of the session protocol.
-
-
- 5.7.3.3 Reuse of Transport Connection
-
- Reuse of a transport connection is not required and can be
- refused.
-
-
- 5.7.3.4 Use of Transport Expedited Data
-
- The use of transport expedited service is as stated in the
- session protocol specification: if available, transport
- expedited service must be used.
-
-
- 5.7.3.5 Use of Session Version Number
-
- Session versions 1 and 2 are recognized. Each relevant NBS
- SIG chooses the version or versions of Session which it
- requires for a particular implementation phase, and these
- choices are documented in section 5.9.1.
-
- Session version 2 specifies the use of unlimited user data
- during connection establishment as dictated by the DAD 2 to
- ISO 8327 to Incorporate Unlimited User Data.
-
- All Session version 1 implementations must be able to
- negotiate version 1 operation when responding to a CONNECT
- (CN) SPDU proposing both version 1 and version 2.
-
- In addition, all Session version 1 implementations, upon
- receipt of a CONNECT (CN) SPDU proposing only version 2,
- should respond with a REFUSE (RF) SPDU containing a Reason
- Code indicating that the proposed version is not supported.
- Until pending defect reports are adopted, implementations
- may disconnect.
-
- If Session versions 1 and 2 are both proposed in the CONNECT
- (CN) SPDU, then the maximum length of the User Data
- parameter value in the CONNECT (CN) SPDU shall be 512 octets
- and a PGI field of 193 shall be associated with this
- parameter. This implies that an implementation supporting
- both Session versions 1 and 2 can establish a connection
- with an implementation supporting only version 1.
-
- If only Session version 2 is proposed in the CONNECT (CN)
- SPDU, then the maximum length of the Session User Data
- parameter value of the S-CONNECT service request shall be
- 10,240 octets. This restriction implies that the OVERFLOW
- ACCEPT (OA) SPDU and CONNECT DATA OVERFLOW (CDO) SPDU are
- not used. If the length of the User Data parameter value is
- no greater than 512 octets, then an associated PGI field of
- 193 shall be used, otherwise a PGI field of 194 shall be
- used.
-
- When Session version 2 is negotiated, then in all SPDUs the
- maximum length of the User Data parameter value with an
- associated PGI field of 193 shall be 10,240 octets. NBS
- conformant Session version 2 implementations need only
- support the maximum data lengths specified in the Specific
- ASE Requirements section.
-
-
- 5.7.3.6 Receipt of Invalid SPDUs
-
- Upon receipt of an invalid SPDU, the SPM shall take any
- action in A.4.3 of the Session protocol definition ISO/IS
- 8327 except action d.
-
-
- 5.7.3.7 Invalid SPM Intersections
-
- If the conditions described in A.4.1.2 of the Session
- protocol definition ISO/IS 8327 are satisfied, the SPM shall
- always take the actions described by A.4.1.2 a.
-
- Note: This implies that no S-P-EXCEPTION-REPORT
- indications will be generated nor EXCEPTION REPORT
- SPDUs sent due to invalid intersections of the
- Session state table resulting from received SPDUs.
-
-
- 5.7.3.8 S-Selectors
-
- S-selectors shall be a maximum of 16 octets.
-
-
-
- 5.8 Universal ASN.1 Encoding Rules
-
-
- 5.8.1 Tags
-
- The maximum value of an ASN.1 basic encoding tag that need be
- handled by an NBS-conformant implementation shall be 16,383.
- This is the maximum unsigned number that can be represented in 14
- bits, therefore, the maximum encoding of a tag occupies 3 octets.
-
-
- 5.8.2 Definite length
-
- The maximum value of an ASN.1 length octets component that need
- be handled by an NBS-conformant implementation shall be
- 4,294,967,295. This is the maximum unsigned integer that can be
- represented in 32 bits, therefore, the maximum encoding of a
- length octets component will occupy 5 octets. Also, note this
- restriction does not apply to indefinite length encoding.
-
-
- 5.8.3 EXTERNAL Type
-
- It is assumed that "presentation layer negotiation of encoding
- rules" is always in effect, and therefore clause 32.5 of the
- Specification of ASN.1, ISO 8824 never applies.
-
-
-
- 5.9 CONFORMANCE
-
- In order for an implementation to be in conformance with the NBS
- implementors' agreements, the following rules shall be adhered to:
-
- o A conformant implementation must meet all of the requirements of
- this specification. All documents referenced in the Upper Layers
- section shall be used as the supporting documents for all
- implementations of ACSE, Presentation, or Session. The full
- references for these documents are in the REFERENCES section.
-
- o NBS conformant implementations shall be ISO conformant. PICS may
- contain limitations on length or value aspects of a protocol.
- PICS of NBS conformant systems shall not contain restrictions
- more severe than those in these implementation agreements. Note:
- an implementation may abort a connection if the constraints
- specified in these agreements are violated.
-
- o Guidelines for implementation of standards' defects will be as
- per the resolution of such defects by the appropriate ISO
- standards committee.
-
-
- 5.9.1 Specific ASE Requirements for ACSE Presentation and
- Session
-
- The following list for each ASE the corresponding NBS SIGs
- requirements of and restrictions on ACSE, Presentation, and
- Session.
-
- All listed requirements and restrictions shall be included in an
- NBS conformant system and shall be implemented in accordance with
- these NBS Implementor's agreements.
-
- All OBJECT IDENTIFIERS are specified in terms of their associated
- ObjectDescriptor's. See the chapter on OBJECT IDENTIFIERs for
- the values of the associated OBJECT IDENTIFIERs.
-
-
- 5.9.1.1 FTAM
-
- 5.9.1.1.1 Phase 2
-
- ACSE Requirements:
- all
-
- Application Contexts:
- o "ISO FTAM" - implies the use of the
- ACSE and the FTAM ASE.
-
- Abstract Syntaxes:
- o "ISO 8650-ACSE1"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- Presentation Requirements:
-
- Presentation Functional Units:
- o kernel
-
- Presentation Contexts:
- o At least 3 Presentation Contexts
- must be supported.
-
- Abstract Syntaxes:
-
- Abstract Syntaxes for conformant
- Implementations
-
- o "FTAM-PCI"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type:
-
- o "FTAM unstructured binary abstract
- syntax"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- Abstract Syntaxes Depending on
- Implementation Profile
-
- o "FTAM-FADU"
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
-
- o "FTAM unstructured text abstract
- syntax"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- o "NBS abstract syntax AS1"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- o "NBS file directory entry abstract
- syntax"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single Asn.1 type"
-
-
- Session Requirements:
-
- Session Functional Units:
- o kernel
- o duplex
-
- Version Number: 2
-
- Maximum size of User Data parameter field:
- 10,240
-
-
- Session Options:
-
- Session Functional Units:
- o resynchronize
- only a Resynchronize Type
- value of "abandon"
-
- o minor synchronize
- Note: The minor
- synchronize
- functional unit is
- required whenever
- the resynchronize
- functional unit is
- available.
-
- 5.9.1.2 MHS
-
-
- 5.9.1.2.1 Phase 1
-
- Session Requirements:
-
- Session Functional Units:
- o kernel
- o half-duplex
- o exceptions
- o activity management
- o minor synchronize
-
- Version Number: 1
-
- Maximum size of User Data parameter field:
- 512
-
- Session Notes:
- o Restricted use is made by the RTS
- of the session services implied by
- the functional units selected.
- Specifically,
-
- . No use is made of S-TOKEN-
- GIVE, and
- . S-PLEASE-TOKENS only asks for
- the data token.
-
- o In the S-CONNECT SPDU, the Initial
- Serial Number should not be
- present.
-
- o The format of the Connection
- Identifier in the S-CONNECT SPDU is
- described in Version 5 of the
- X.400-Series Implementors' Guide.
-
- 5.9.1.3 DS
-
-
- 5.9.1.3.1 Phase 1
-
-
- ACSE Requirements:
- all
-
- Application Context:
-
- Abstract Syntaxes:
- o "ISO 8650-ACSE1"
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- o "Directory Services"
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- Presentation Requirements:
-
- Presentation Functional Units:
- o kernel
-
- Presentation Contexts:
- o At least 2 Presentation Contexts
- must be supported.
-
- Session Requirements:
-
- Session Functional Units:
- o kernel
- o duplex
-
- Version Number: 2
-
- Maximum size of User Data parameter field:
- 10,240
- 5.10 APPENDIX A: RECOMMENDED PRACTICES
-
-
- Reflect Parameter Values
-
- The optional "Reflect Parameter Values" parameter in the provider
- ABORT SPDU shall be encoded so as to represent the Session connection
- state, the incoming event and the first invalid SPDU field exactly at
- the moment a protocol error was detected.
-
- The first octet encodes the Session state as a number relative to 0 as
- detailed in Table 1.
-
- The second octet encodes the incoming event as a number relative to 0
- as detailed in Table 2.
-
- The third octet contains the SI, PGI, or PI Code of any SI field, PGI
- unit or PI unit in error.
-
- NOTE: The remaining 6 octets are undefined herein.
- Table 1 - Session States
-
-
- State rel.# Description
-
- 1 0 Idle, no transport connection
- 1B 1 Wait for T-connect confirm
- 1C 2 Idle, transport connected
- 2A 3 Wait for the ACCEPT SPDU
- 3 4 Wait for the DISCONNECT SPDU
- 8 5 Wait for the S-CONNECT response
- 9 6 Wait for the S-RELEASE response
- 16 7 Wait for the T-DISCONNECT indication
- 713 8 Data Transfer state
- 1A 9 Wait for the ABORT ACCEPT SPDU
- 4A 10 Wait for the MAJOR SYNC ACK SPDU or PREPARE
- SPDU
- 4B 11 Wait for the ACTIVITY END ACK SPDU or PREPARE
- SPDU
- 5A 12 Wait for the RESYNCHRONIZE ACK SPDU or PREPARE
- SPDU
- 5B 13 Wait for the ACTIVITY INTERRUPT SPDU or PREPARE
- SPDU
- 5C 14 Wait for the ACTIVITY DISCARD ACK SPDU or
- PREPARE
- SPDU
- 6 15 Wait for the RESYNCHRONIZE SPDU or PREPARE
- SPDU
- 10A 16 Wait for the S-SYNC-MAJOR response
- 10B 17 Wait for the S-ACTIVITY-END response
- 11A 18 Wait for the S-RESYNCHRONIZE response
- 11B 19 Wait for the S-ACTIVITY-INTERRUPT response
- 11C 20 Wait for the S-ACTIVITY-DISCARD response
- 15A 21 After PREPARE, wait for the MAJOR SYNC ACK SPDU or the
- ACTIVITY END ACK
- 15B 22 After PREPARE, wait for the RESYNCHRONIZE SPDU or the
- ACTIVITY DISCARD SPDU
- 15C 23 After PREPARE, wait for the RESYNCHRONIZE ACK SPDU, or
- the ACTIVITY INTERRUPT ACK SPDU or the ACTIVITY
- DISCARD ACK SPDU
- 18 24 Wait for GIVE TOKENS ACK SPDU
- 19 25 Wait for a recovery request or SPDU
- 20 26 Wait for a recovery SPDU or request
- 21 27 Wait for the CAPABILITY DATA ACK SPDU
- 22 28 Wait for the S-CAPABILITY-DATA response
- 1D 29 Wait for the CONNECT DATA OVERFLOW SPDU
- 2B 30 Wait for the OVERFLOW ACCEPT SPDU
- 15D 31 After PREPARE, wait for the ABORT SPDU
- Table 2 - Incoming Events
-
-
- Event Rel.# Description
-
- SCONreq 0 S-CONNECT request
- SCONrsp+ 1 S-CONNECT accept response
- SCONrsp- 2 S-CONNECT reject response
- SDTreq 3 S-DATA request
- SRELreq 4 S-RELEASE request
- SRELrsp+ 5 S-RELEASE accept response
- SUABreq 6 S-U-ABORT request
- TCONcnf 7 T-CONNECT confirmation
- TCONind 8 T-CONNECT indication
- TDISind 9 T-DISCONNECT indication
- TIM 10 Time out
- AA 11 ABORT ACCEPT
- AB-nr 12 ABORT - no reuse
- AC 13 ACCEPT
- CN 14 CONNECT
- DN 15 DISCONNECT
- DT 16 DATA TRANSFER
- FN-nr 17 FINISH - no reuse
- RF-nr 18 REFUSE - no reuse
- SACTDreq 19 S-ACTIVITY-DISCARD request
- SACTDrsp 20 S-ACTIVITY-DISCARD response
- SACTEreq 21 S-ACTIVITY-END request
- SACTErsp 22 S-ACTIVITY-END response
- SACTIreq 23 S-ACTIVITY-INTERRUPT request
- SACTIrsp 24 S-ACTIVITY-INTERRUPT response
- SACTRreq 25 S-ACTIVITY-RESUME request
- SACTSreq 26 S-ACTIVITY-START request
- SCDreq 27 S-CAPABILITY-DATA request
- SCDrsp 28 S-CAPABILITY-DATA response
- SCGreq 29 S-CONTROL-GIVE request
- SEXreq 30 S-EXPEDITED-DATA request
- SGTreq 31 S-TOKEN-GIVE request
- SPTreq 32 S-TOKEN-PLEASE request
- SRELrsp- 33 S-RELEASE response reject
- SRSYNreq(a) 34 S-RESYNCHRONIZE request abandon
- SRSYNreq(r) 35 S-RESYNCHRONIZE request restart
- SRSYNreq(s) 36 S-RESYNCHRONIZE request set
- SRSYNrsp 37 S-RESYNCHRONIZE response
- SSYNMreq 38 S-SYNC-MAJOR request
- SSYNMrsp 39 S-SYNC-MAJOR response
- SSYNmreq 40 S-SYNC-MINOR request
- SSYNmrsp 41 S-SYNC-MINOR response
- STDreq 42 S-TYPED-DATA request
- SUERreq 43 S-U-EXCEPTION-REPORT request
- AB-r 44 ABORT - reuse SPDU
- Table 2 - continued
-
-
- Event Rel.# Description
-
- AD 45 ACTIVITY DISCARD SPDU
- ADA 46 ACTIVITY DISCARD ACK SPDU
- AE 47 ACTIVITY END SPDU
- AEA 48 ACTIVITY END ACK SPDU
- AI 49 ACTIVITY INTERRUPT SPDU
- AIA 50 ACTIVITY INTERRUPT ACK SPDU
- AR 51 ACTIVITY RESUME SPDU
- AS 52 ACTIVITY START SPDU
- CD 53 CAPABILITY DATA SPDU
- CDA 54 CAPABILITY DATA ACK SPDU
- ED 55 EXCEPTION DATA SPDU
- ER 56 EXCEPTION REPORT SPDU
- EX 57 EXPEDITED DATA SPDU
- FN-r 58 FINISH - reuse SPDU
- GT 59 GIVE TOKENS SPDU
- GTA 60 GIVE TOKENS ACK SPDU
- GTC 61 GIVE TOKENS CONFIRM SPDU
- MAA 62 MAJOR SYNC ACK SPDU
- MAP 63 MAJOR SYNC POINT SPDU
- MIA 64 MAJOR SYNC ACK SPDU
- MIP 65 MINOR SYNC POINT SPDU
- NF 66 NOT FINISHED SPDU
- PR-MAA 67 PREPARE (MAJOR SYNC ACK) SPDU
- PR-RA 68 PREPARE (RESYNCHRONIZE ACK) SPDU
- PR-RS 69 PREPARE (RESYNCHRONIZE) SPDU
- PT 70 PLEASE TOKENS SPDU with Token Item
- Parameter
- RA 71 RESYNCHRONIZE ACK SPDU
- RF-r 72 REFUSE - reuse SPDU
- RS-a 73 RESYNCHRONIZE - abandon SPDU
- RS-r 74 RESYNCHRONIZE - restart SPDU
- RS-s 75 RESYNCHRONIZE - set SPDU
- TD 76 TYPED DATA SPDU
- CDO 77 CONNECT DATA OVERFLOW SPDU
- OA 78 OVERFLOW ACCEPT SPDU
- PR-AB 79 PREPARE (ABORT) SPDU6. ISO FILE TRANSFER, ACCESS AND MANAGEMENT PHASE 2
-
- 6.1 INTRODUCTION
-
- This section defines Implementors' Agreements based on ISO File
- Transfer, Access and Management (FTAM), as defined in ISO 8571. This
- International Standard has four parts. Part 1 of the IS gives general
- concepts, Part 2 defines the Virtual Filestore (VFS), Part 3 defines
- the File Service, and Part 4 defines the File Protocol.
-
- FTAM, as described in the IS, is based on the following ISO documents:
- ACSE Service and Protocol (ISO 8649, ISO 8650), Presentation Service
- and Protocol (ISO 8822, ISO 8823), ASN.1 Abstract Syntax Notation and
- Basic Encoding Rules (ISO 8824, ISO 8825), and Session Service and
- Protocol (ISO 8326, ISO 8327). These services and protocols are
- defined architecturally in the OSI Reference Model (ISO 7498). These
- Agreements provide detailed guidance for the implementor, and
- eliminate ambiguities in interpretations.
-
- The general agreements reached with respect to the ISO File Transfer,
- Access and Management Protocol (FTAM) are that the Phase 2 FTAM
- specification (this section) is based on the International Standard
- (IS).
-
-
- 6.2 SCOPE AND FIELD OF APPLICATION
-
- These FTAM Phase 2 Agreements cover transfer of and access to files
- between the Filestores of two end systems, including the management of
- a Virtual Filestore. One end system acts in the Initiator role and
- initiates the file transfer/access, while the other end system acts in
- the Responder role and provides access to the file in the Virtual
- Filestore. This paper describes Agreements for the actions and
- attributes of the Virtual Filestore, and the service provided by the
- file service provider to file service users, together with the
- necessary communications between the Initiator and Responder.
-
-
- ZDDDDDDDDDDDDDD?
- 3 Virtual 3
- 3 Filestore 3
- 3 2 3
- @DDDDDDRDDDDDDDY
- :
- :
- ZDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDD? ZDDDDDDPDDDDDDD? ZDDDDDDDDDDDDDD?
- 3 Real 3 3 End 3 3 End 3 3 Real 3
- 3 Filestore CDDDD4 System 1 FMMMM5 System 2 CDDDD4 Filestore 3
- 3 1 3 3- Initiator - 3 3- Responder - 3 3 2 3
- @DDDDDDDDDDDDDDY @DDDDDDDDDDDDDDY @DDDDDDDDDDDDDDY @DDDDDDDDDDDDDDY
-
-
- Figure 6.1 Model of file transfer/access
-
-
- Note: Agreements apply on the double lines of Figure 1.
- The mapping between the Virtual Filestore and the Real Filestore
- together with the local data management system is not part of
- these Agreements.
-
- These Agreements define General Agreements is in section 6.5 through
- 6.16, minimum functionality (Conformant Implementations) in section
- 6.17, and functionality for several Implementation Profiles which are
- tailored to different classes of user requirements in sections 6.18
- and 6.19.
-
-
- 6.3 STATUS
-
- This version of the FTAM Implementation Agreements was completed
- December 18, 1987. No further enhancements will be made to this
- version. See the next section, ERRATA.
-
- Note: These Agreements were updated from the previous March 1987 DIS
- based Agreements.
-
- 6.4 ERRATA
- ZDDDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDBDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3CP no 3Type 3ref. doc 3section 3Comment 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-1 3technical3NBS 500-15036.10.2.2, 3Check of already established presentation 3
- 3 3 3 36.10.2.3 3context for a document type not at CREATE time 3
- 3 3 3 3 3but at OPEN time 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-2 3editorial3NBS 500-15036, App. A, 3Appendix A, Part 4 of Object Identifiers 3
- 3 3 3 3Part 4 3removed 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-3 3editorial3NBS 500-15036.5 3Clarification that current AET definition 3
- 3 3 3 3new bullet 3carries no semantics and other values are 3
- 3 3 3 37 3outside scope. 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-4 3technical3NBS 500-15035.9 3Clarification for UL specs that ABORT possible 3
- 3 3 3 3 3if UL constraints are violated 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-5 3editorial3NBS 500-15036, App. A 3Replace 'organ-code' by 'organization-code' for3
- 3 3 3 3 3all NBS Object Identifiers 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-6 3editorial3NBS 500-15036.5 3Clarification that <shared ASE information> 3
- 3 3 3 3new bullet 3and <application context name> agreements are 3
- 3 3 3 38,9 3general agreements 3
- 3 3 3 36.18.3 3 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-7 3editorial3NBS 500-15036.18.2 3Move 6.18.2 to new Section 6.17.9 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-8 3editorial3NBS 500-1503Table 6.4 3Rendition of currency sign in table 6.4 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-9 3editorial3NBS 500-15036.2, 6.17 3Clarification of meaning of General Agreements,3
- 3 3 3 3 3Conformance and Implementation Profiles 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 2/88-10 3editorial3NBS 500-15036.5 3Definition of 's', 'os' for a parameter. 3
- 3 3 3 3new bullet 3Clarification of support level for <initiator 3
- 3 3 3 310, 6.18.3 3identity>, <filestore password>, <access 3
- 3 3 3 3bullet 5 3password> parameter 3
- 3 3 3 36.16.1 3 3
- 3 3 3 36.16.2 3 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 5/88-1 3editorial3NBS 500-1503Table 6.7 3Clarification fo support of T&M service class 3
- 3 3 3 3Note 4 3 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 5/88-2 3editorial3NBS 500-15036.18.3 3Remove <charging> value zero 3
- 3 3 3 3bullet 6 3 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 5/88-3 3editorial3NBS 500-1503Table 6.9 3Updated definition of Datatype 2 3
- CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3CP 5/88-4 3editorial3NBS 500-15036.5, new 3More clarification to CP 2/88, use of AETitle 3
- 3 3 3 3bullet 7 3values 3
- @DDDDDDDDDDDADDDDDDDDDADDDDDDDDDDDADDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- 6.5 ASSUMPTIONS
-
- 1. FTAM protocol machines must be able to parse and process at a
- minimum 7K octets of FTAM PCI and FTAM user data (including
- grouped FPDUs) as they would be encoded with the ASN.1 Basic
- Encoding Rules. It is recommended, however, that Presentation
- user data not be restricted in size.
-
- 2. In order to maximize interoperability, it is important that the
- implementations of FTAM service providers do not unnecessarily
- restrict the service user's ability to generate arbitrary file
- service requests. Otherwise, they may not be able to work with
- FTAM Responders whose operation is constrained by their mapping
- of the FTAM Virtual Filestore to their local filestore. For
- example, error procedures should only be invoked when an error
- actually occurs, not at the point of the specification of
- options which might result in an error.
-
- 3. Implementations must be able to parse all valid optional
- parameters if they are present in the PDU. Only those optional
- parameters specified as supported in these Agreements are
- required to be implemented. If these parameters are not present,
- a default value is assigned locally. A Responder should not
- refuse a request solely because a parameter that is optional in
- the FTAM standard, but is supported in these Agreements, is not
- present.
-
- 4. Consideration of any standardized service interface is not
- covered by these Agreements.
-
- 5. These Agreements define no restrictions for the values used for
- the <communication quality of service> parameter in <F-
- INITIALIZE>.
-
- 6. FTAM is defined in phases. The Phase 1 FTAM implementation
- specification is based on the second ISO Draft Proposal, dated
- April 1985, and the ISO Draft Proposal 8824 and 8825.
-
- The Phase 2 FTAM specification (this section) is based on the
- International Standard (IS). THERE IS NO BACKWARD COMPATIBILITY
- WITH NBS FTAM PHASE 1. Backward compatibility is impossible,
- since Phase 1 uses Session services directly, while Phase 2 uses
- ACSE and Presentation services. Furthermore, there are
- differences in Filestore, PDU Abstract Syntax, FADU Abstract
- Syntax, and Transfer Syntax. There also are differences in the
- transparency mechanisms and service class negotiations.
-
- The <implementation information> parameter of <F-INITIALIZE> FPDU
- as defined in ISO 8571-4, 20.3 is used to pass 'user version'
- information with respect to different FTAM phases of the NBS
- Implementors Agreements or with respect to FTAM profiles of other
- bodies (see section 6.13 6.12 of this document). It is the goal
- of these Agreements to use the 'user version' mechanism to
- provide at least one level of backward compatibility for all
- future NBS FTAM Phases, facilitating backward compatibility for
- future FTAM products, assuming different new versions of the
- respective IS's also enable backward compatibility.
-
- 7. Section 5.5.3 5.5.3.3 defines a value (that carries no semantics)
- for the AETitle that can be used by FTAM ASEs for communication.
- Other values for the AETitle are outside the scope of these
- Agreements.
-
- For the Called-AETitle, Calling-AETtitle and Responding AETitle
- the association shall not be rejected/aborted if the value
- specified in 5.5.3.3 is sent or if any of the parameters are not
- sent. The association may be rejected/aborted if a value other
- than specified in 5.5.3.3 is sent.
-
- Use of values outside the scope of these Agreements is
- discouraged until agreed upon semantics have been associated with
- AETitles.
-
- 8. Use of <shared ASE information> parameter and <charging>
- parameter is not defined within the scope of the Agreements.
-
- 9. Use of <application context name> parameter is not defined within
- the scope of these Agreements. This parameter does not prohibit
- the establishment of an FTAM association.
-
- 10. These Agreements use the term 'supported' for a parameter to mean
- that the syntax and semantics of that parameter shall be
- implemented. However, it is not a requirement that the parameter
- be used in all instances of communication, unless stated
- otherwise.
-
- Also these Agreements use the term 'optionally supported' for a
- parameter to mean that it is left to the implementation whether
- the semantics of that parameter are implemented or not.
-
-
- 6.6 PRESENTATION AGREEMENTS
-
- The following Abstract Syntaxes are recognized in these agreements:
-
- "FTAM FADU"
- "FTAM PCI"
- "FTAM unstructured text abstract syntax"
- "FTAM unstructured binary abstract syntax"
- "NBS abstract syntax AS1"
- "NBS file directory entry abstract syntax"
-
- The following Transfer Syntax is supported:
-
- "Basic Encoding of a single ASN.1 type"
- (See Appendix A, Part 3)
-
-
- 6.7 SERVICE CLASS AGREEMENTS
-
- Implementation Agreements have been reached for the following service
- classes.
-
- o File Transfer
- o File Access
- o File Management
- o File Transfer and Management
- o Unconstrained
-
-
- 6.8 FUNCTIONAL UNIT AGREEMENTS
-
- Implementation agreements have been reached for the following
- functional units.
-
- o Kernel
- o Read
- o Write
- o File Access
- o Limited File Management
- o Enhanced File Management
- o Grouping
-
- Implementation of the Recovery, Restart Data Transfer, and FADU
- Locking functional units is not specified.
-
-
- 6.9 FILE ATTRIBUTE AGREEMENTS
-
- Implementation of the Kernel Group of file attributes is defined. If
- the optional Storage Group and Security Group are implemented, aspects
- of their implementation are defined. Implementation of the Private
- Group is not specified.
-
- Responses to an attribute value request shall always include one of
- the following (as specified in ISO 8571-2, clause 9.4):
-
- o An actual file attribute value.
-
- o A value indicating that no value is available, optionally with a
- diagnostic.
-
- o No value and an error code, optionally with a diagnostic
- indicating that the attribute is not supported.
-
-
- 6.9.1 Mandatory Group
-
- Only the Kernel Group of attributes is required. A value for
- <filename>, <permitted actions>, and <contents type> will always
- be available.
-
- A minimum range is required for <filename> values as specified in
- ISO 8571-2. No maximum length or format restrictions apply. A
- system that does not support <filename> values with a sequence of
- more than one Graphic String or extended <filename>
- characteristics may reject a request involving such a <filename>.
- All systems must be able to interpret a <filename> value with a
- sequence of one Graphic String. Requests using such a single
- component <filename> value with a sequence of one Graphic String
- are responded to using a single component <filename> value.
- Responses to requests involving <filename> values having two or
- more Graphic Strings are not defined here but may be interpreted
- via bilateral or other external agreements. Use of <filename>
- values with a sequence of more than one Graphic String is
- discouraged.
-
- Apart from the minimum conformance requirements specified in ISO
- 8571-2, file names have to be specified in the naming convention
- of the responding FTAM implementation. It is a local
- implementation matter of the FTAM Responder, whether or not an
- additional name mapping onto the real FIlestore's file name
- convention is supported.
-
- In order to enable interworking with all FTAM Responders' virtual
- Filestores, it is recommended that FTAM Initiators impose no
- restrictions on the attribute range supported for file names
- beyond those specified in ISO 8571-2.
-
- For the purpose of interworking according to these Agreements the
- <contents type> attribute is limited to the <document type name>
- format. The <constraint set name, abstract syntax name> form is
- outside the scope of these Agreements. It should always be
- parsed correctly when received, but may result in an error.
-
- 6.9.2 Optional Groups
-
- If the optional Security Group of file attributes is implemented,
- an actual value must be available for the <access control>
- attribute.
-
- The <access control> attribute is a SET OF <access control
- element>. The minimum requirement in these Agreements is the
- support of one <access control element>, according to the base
- standard. The terms <concurrency access>, <identity>, and
- <passwords> are each optionally supported. Details of their use
- shall be specified in the PICS. Use of the <location> term is
- not specified in these Agreements.
-
- Implementation of the Private Group is not specified.
-
-
- 6.10 DOCUMENT TYPE AGREEMENTS
-
- These document types are defined.
-
- FTAM-1 "ISO FTAM unstructured text"
- FTAM-2 "ISO FTAM sequential text"
- FTAM-3 "ISO FTAM unstructured binary"
- NBS-6 "NBS-6 FTAM sequential file"
- NBS-7 "NBS-7 FTAM random access file"
- NBS-8 "NBS-8 FTAM indexed file"
- NBS-9 "NBS-9 FTAM file directory file"
-
- Detailed document type definitions are given in Appendix 6A and in ISO
- 8571-2, Annex B.
-
- Note: Document types NBS-1 to NBS-5 are not defined in these
- Agreements. The numbering starts with NBS-6 because of the original
- DIS version of these Agreements.
-
- An implementation claiming conformance to these Agreements which also
- supports any or all of the document types FTAM-1, FTAM-2, and FTAM-3
- as defined in ISO 8571-2, Annex B, must minimally support the
- combinations of parameter values as specified in Table 6.1.
-
-
- Table 6.1 Parameters for FTAM-1, -2, -3
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Universal Maximum String 3
- 3 Class Number String Length6 Significance 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 FTAM-1 General String 1(27) 134 or less 'not-significant'3
- 3 IA5String 2(22) 3
- 3 3
- 3 FTAM-2 Graphic String 3,4(25) 134 or less5 'not-significant'3
- 3 3
- 3 3
- 3 FTAM-3 <not applicable> 512 or less 'not-significant43
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- Notes:
- 1. The minimum level of support for General String is the IA5 G0
- character set and the 8859-1 G0 and G1 character sets, and IA5 C0
- set.
-
- 2. The support for IA5 String is the IA5 G0 character set and the
- IA5 C0 set.
-
- 3. The minimum level of support for Graphic String is the IA5 G0
- character set and the 8859-1 G0 and G1 sets.
-
- 4. This is the default when the parameter is not specified.
-
- 5. The implementation need not support Data Units whose total
- character count exceeds 134.
-
- 6. As per Table 6.3.
-
- For the use of FTAM-2 only the FADU identities of 'begin', 'end',
- 'first', and 'next' are required for conformant implementations.
-
- For the document types NBS-6, NBS-7 and NBS-8 parameters are used for
- which the Agreements apply as specified in Table 6.2.
- Table 6.2 Parameters for NBS-6, NBS-7, NBS-8
-
- ZDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
- 3 Parameter 3 PrimType 3 String-length 3 Length-1 3 Length-2 3
- CDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3
- 3 int 3 INTEGER 3 Number of octets 3 3 3
- 3 3 3 required to represent,3 3 3
- 3 3 3 in 2's complement 3 3 3
- 3 3 3 format, the largest 3 3 3
- 3 3 3 integer to be passed 3 3 3
- 3 3 3 3 3 3
- 3 bit 3 BIT STRING 3 Number of bits in 3 3 3
- 3 3 3 string 3 3 3
- 3 3 3 (non-varying) 3 3 3
- 3 3 3 3 3 3
- 3 ia5 3 IA5String 3 Max number of 3 3 3
- 3 3 3 characters in string 3 3 3
- 3 3 3 3 3 3
- 3 graphic 3 Graphic 3 Max number of 3 3 3
- 3 3 String 3 characters in string 3 3 3
- 3 3 3 3 3 3
- 3 3 3 3 3 3
- 3 general 3 General 3 Max number of 3 3 3
- 3 3 String 3 characters in string 3 3 3
- 3 3 3 3 3 3
- 3 3 3 3 3 3
- 3 octet 3 OCTET STRING3 Max numbers of octets 3 3 3
- 3 3 3 in string 3 3 3
- 3 3 3 3 3 3
- 3 private- 3 Floating 3 3 The minimum 3 Number of bits 3
- 3 class-number 3 Point 3 3 number of bits 3 required to 3
- 3 3 Number 3 3 required to be 3 represent the 3
- 3 3 3 3 maintained in 3 largest unbiased3
- 3 3 3 3 the mantissa for3 integer exponent3
- 3 3 3 3 relative 3 in 2's 3
- 3 3 3 3 precision 3 complement 3
- 3 3 3 3 3 3
- 3 3 3 3 3 3
- 3 3 3 3 3 3
- 3 3 3 3 3 3
- 3 univer- 3 UTCTime 3 <not applicable> 3 3 3
- 3 time 3 3 3 3 3
- 3 3 3 3 3 3
- 3 gen-time 3 Generalized 3 <not applicable> 3 3 3
- 3 3 Time 3 3 3 3
- 3 3 3 3 3 3
- 3 boolean 3 BOOLEAN 3 <not applicable> 3 3 3
- 3 3 3 3 3 3
- 3 null 3 NULL 3 <not applicable> 3 3 3
- 3 3 3 3 3 3
- @DDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDY
-
- Note: The string length parameter specifies the actual number of
- characters from the referenced character set. It does not include any
- escape sequences or overhead from the encoding.
-
- The primitive data types and minimal size ranges that an
- implementation must accept for storage are given in Table 6.3.
-
-
- Table 6.3 FTAM primitive data types
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Primitive Data Type Minimum Range (Octets)3
- 3 3
- 3ASN.1 INTEGER 1 - 2 3
- 3ASN.1 BIT STRING 0 - 1 3
- 3ASN.1 IA5String 0 - 134 3
- 3ASN.1 GeneralString 0 - 134 3
- 3ASN.1 GraphicString 0 - 134 3
- 3ASN.1 OCTET STRING 0 - 512 3
- 3ASN.1 BOOLEAN 3
- 3ASN.1 NULL 3
- 3ASN.1 GeneralizedTime 3
- 3ASN.1 UniversalTime 3
- 3NBS-AS1 FloatingPointNumber mantissa 1-23 bits 3
- 3 exponent 0-8 bits 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Notes:
- 1. The primitive data types and their maximum ranges for a specific
- file as described by the parameters above are maintained in the
- <contents type> file attribute. The <contents type> file
- attribute value is established at the file's creation and cannot
- be changed via FTAM for the life of the file. This implies that
- the data element types and ranges and data unit formats are fixed
- for all accessors of that file as long as the file exists.
-
- 2. The syntax for floating point numbers is part of the definition
- of NBS abstract syntax AS1 in Annex 6A Part 3. It is derived
- from existing standards IEC 559 and IEEE 754.
-
-
- 6.10.1 Character Sets
-
- Implementation of a character set in FTAM is understood as:
-
- o a transfer syntax is defined for the character set
-
- o document types are defined using the character set in
- their abstract syntactic definition
-
- o documents of those types are stored in the Virtual File
- Store as defined in the character set specification.
- They are written into the VFS and read from the VFS as
- defined by the abstract syntax and the transfer syntax
- for the document type. It is not in the scope of FTAM
- Agreements to specify the local representation of those
- documents in the Real Filestore, nor to specify
- rendition of graphic characters or control characters
- on character imaging devices. These renditions are
- possible agreements between applications using FTAM for
- their communication.
-
- The character sets IA5 and ISO 8859-1 shall always be
- implemented.
-
-
- 6.10.1.1 IA5 Character Set
-
- The International Reference Version (IRV) of IA5 is
- available for use when there is no requirement to use a
- national or an application-oriented version. In information
- interchange, the IRV is assumed unless a particular
- agreement exists between sender and receiver of the data.
- The graphic characters allocated to the IRV are as specified
- in Table 6.4.
-
- Table 6.4. IRV Graphic Character Allocations
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Graphic Name Coded Representation 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 # Number sign 2/3 3
- 3 3
- 3 o Currency sign 2/4 3
- 3 3
- 3 @ Commercial at 4/0 3
- 3 3
- 3 [ Left square bracket 5/11 3
- 3 3
- 3 \ Reverse solidus 5/12 3
- 3 3
- 3 ] Right square bracket 5/13 3
- 3 3
- 3 ^ Circumflex accent 5/14 3
- 3 3
- 3 ' Grave accent 6/0 3
- 3 3
- 3 { Left curly bracket 7/11 3
- 3 3
- 3 3 Vertical line 7/12 3
- 3 3
- 3 } Right curly bracket 7/13 3
- 3 3
- 3 ~ Tilde, overline 7/14 3
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- It should be noted that no substitution is allowed when using the IRV
- and that the facility of combined vertical and horizontal movements of
- the active position does not apply to any format effectors.
-
- It is permitted to use composite graphic characters and there is no
- limit to their number. Because of this freedom, their processing and
- imaging may cause difficulties at the receiving end. Therefore
- agreement between sender and receiver of the data is recommended if
- composite characters are used.
-
- Note: Attention is drawn to the fact that different national
- character sets exist.
-
- (See ISO 646 or CCITT Recommendation T.50 for more information)
-
-
- 6.10.1.2 8859-1 Character Set
-
- The Latin Alphabet No.1 (ISO 8859-1) is used to specify the
- printable characters of G0 and G1. C0 control characters
- and their associated rules are taken from the IA5
- definition.
-
- 6.10.2 Document Type Negotiation Rules
-
-
- 6.10.2.1 Connection Establishment
-
- In connection establishment the <contents type list>
- parameter is used only to establish presentation contexts.
- Both the <document type name> form and the <abstract syntax
- name> form are supported.
-
-
- 6.10.2.2 File Creation
-
- An <F-CREATE request> FPDU must contain a <document type
- name> value in its <initial attributes> parameter.
-
- If the specified document type requires parameterization,
- then these parameters must be supplied, otherwise the <F-
- CREATE request> may be rejected.
-
- Notes:
- 1. It is understood that <permitted actions> sub-
- field of <initial attributes> parameter will
- always be used at <F-CREATE request>. The value
- may be changed by the Responder.
-
- 2. If the <document type name> used requires DU
- syntax parameters and one of the parameters
- specifies 'FloatingPointNumber' as a primitive
- data type, the request may be rejected, in case
- the optional type 'FloatingPointNumber' is not
- supported by the Responder.
-
-
- 6.10.2.3 File Opening
-
- The <document type name> form (with appropriate parameters
- as specified in 8871-2, clause 12.3) shall always be used
- when proposing a <contents type>; as an alternative the
- 'ContentsTypeUnknown' value may be used in the <F-OPEN
- request>. An <F-OPEN response> shall use the <document type
- name> option (with appropriate parameters) in the <contents
- type> field.
-
- This allows the receiving entity to use the <document type
- name> attributed to the file instead of receiving a
- <constraint set name> and <abstract syntax name> pair, which
- does not reflect the file information contained in the FTAM
- and NBS document types.
-
- This document type name is either a value from the set of
- base document type names as negotiated upon connection
- establishment or a document type name, for which an
- appropriate presentation context was established.
-
- Notes:
- 1. An <F-OPEN response> without a <document type name>
- (but carrying the <constraint set name> and <abstract
- syntax name> form) may cause the Initiator to issue an
- <F-CLOSE request>.
-
- 2. If the <document type name> used requires DU syntax
- parameters and one of the parameters specifies
- 'FloatingPointNumber' as a primitive data type, the
- request may be rejected, in case the optional type
- 'FloatingPointNumber' is not supported by the
- Responder.
-
- 6.10.3 Relationship Between DUs, DEs and Document Types
-
- "Abstract Syntax" is used to refer to the syntactic information
- which is architecturally passed between the Application and
- Presentation Layers. The Abstract Syntax defines Data Element
- (DE) types which are not necessarily ASN.1 primitive types. A
- Data Element (DE) is the smallest piece of data whose identity is
- necessarily preserved by the Presentation Service. Data types
- may be made up of other data types. Data Elements are not
- defined in terms of other Data Elements.
-
- A Data Unit (DU) is a sequence of one or more Data Elements.
- Architecturally, entire, single DEs are passed into and out of
- the application process. In a real implementation, DUs may be
- passed.
-
- To maintain DU boundaries during transfer, file structuring
- information must be passed (ISO8571-FADU definition in ISO 8571-
- 2, clause 7.5). A Data Element is referred to as a File-
- Contents- Data-Element in the ISO8571-FADU definition.
-
- Document types refer to aspects of local processing and storage.
- They describe:
-
- o structural relationship between DUs,
- o structure of DUs, called DU syntax, and
- o DE types found in the file.
-
- Because document types pertain to local processing and storage,
- the DU syntax makes assertions about the syntax and the size of
- DUs (records) in storage. Parameters on the document types
- provide this information about the syntax and size of the DUs.
-
-
- 6.11 F-CANCEL ACTION
-
- When an F-CANCEL is sent or received, the following occurs:
-
- o no more data is sent,
- o checkpoint numbers are removed, and
- o state of the file is implementation dependent.
-
- Note: When mapping F-CANCEL on P-RESYNCHRONIZE (abandon) it is
- required that P-SYNC-MINOR be used after F-READ/F-WRITE (see
- ISO 8571-4 clauses 13, 14).
-
-
- 6.12 IMPLEMENTATION INFORMATION AGREEMENTS
-
- o The <implementation information> parameter of <F-INITIALIZE>
- FPDU is not required by these Agreements.
-
- o It may be used to pass user version information as a series of
- values, separated by ';'.
-
- o The following will indicate conformance to the NBS Phase 2
- Agreements: NBS-Phase2.
-
- Note: The list of possible values may be enlarged for future
- FTAM phases or FTAM profiles of other bodies.
-
- o This parameter is for information only; it is not used for
- negotiation.
-
- The establishment of an FTAM regime should not be rejected only
- because of an unknown <implementation information> value.
-
- 6.13 DIAGNOSTIC AGREEMENTS
-
- o The <diagnostic> parameter is supported; a value in the
- <response> PDU is needed when the <action result> or <state
- result> is not zero. (The nature of these agreements is to
- provide <diagnostic> information when any result parameter is not
- 'success'.)
-
- o General catch-all diagnostic action is discouraged.
-
- o The <further details> subfield is supported. It will be encoded
- as GraphicString, but is restricted to IA5 (IRV, graphic
- characters) and ISO 8859-1 only.
-
- o Use of F-P-ABORT for other than protocol errors and catastrophic
- situations is discouraged.
-
- o When returning an error status in a file management related
- diagnostic (i.e., <F-READ-ATTRIBUTE response> or <F-
- CHANGE-ATTRIBUTE response>), identify the erroneous attribute by
- using the first two characters of <further details> to hold a
- 2-digit number (encoded as IA5String) from the <F-READ-ATTRIBUTE
- request> attributes abstract syntax definition (ISO 8571-4,
- clause 20.3).
-
- 00 Filename
- 01 Permitted Actions
- 02 Contents Type
- 03 Storage Account
- 04 Date and Time of Creation
- 05 Date and Time of Last Modification
- 06 Date and Time of Last Read Access
- 07 Date and Time of Last Attribute Modification
- 08 Identity of Creator
- 09 Identity of Last Modifier
- 10 Identity of Last Reader
- 11 Identity of Last Attribute Modifier
- 12 File Availability
- 13 File Size
- 14 Future Filesize
- 15 Access Control
- 16 Legal Qualifications
- 17 Private Use
-
- The set of file management diagnostics, found in ISO 8571-3 Annex
- A, must be supported.
-
- o In the case where a specific parameter can in no way be
- accommodated then the request fails and a <diagnostic> indicating
- one such parameter should be returned by the responder. In the
- case where a negotiable parameter cannot be accommodated with
- exactly the value requested but is negotiated to a different
- value (as defined in the standard) then the request formally
- succeeds but informative <diagnostics> indicating those
- parameters negotiated should be returned.
-
- o In order to provide for robust applications using FTAM, well
- defined and precise diagnostics are required to be returned by
- responding implementations whenever an action cannot be carried
- out precisely as requested with respect to non-negotiable
- parameters. All such applicable diagnostics will be returned in
- those cases. An action is carried out precisely as requested
- with respect to a parameter when the value of that parameter on
- the <request> FPDU is equal to the value in effect during or
- subsequent to the action, depending on whether the action is
- regime control.
-
- Diagnostics exist to signal 'parameter not supported' and
- Responder implementations shall issue all appropriate
- diagnostics. The <further details> subfield of the <diagnostic>
- parameter shall specify the parameter which is not implemented.
-
- 6.14 CONCURRENCY
-
- The <concurrency control> used by default on actions requested by an
- <F-SELECT indication> or <F-CREATE indication> service are:
-
- 'shared' for read and read attribute
-
- 'exclusive' for all other actions
-
- The default for actions not requested is specified as 'not required'
- as per ISO 8571-3.
-
- Note: A local implementation may choose to be more restrictive in
- order to assure file consistency for concurrent accessors.
-
- FADU locking is not required.
-
- 6.15 REQUESTED ACCESS
-
- The <requested access> parameter on <F-SELECT> or <F-CREATE> is used
- to specify the actions which the Initiator may perform during the file
- selection. The value of the <requested access> parameter is compared
- by the Responder to the <access control> and <permitted actions> file
- attributes and concurrency controls (including those requested by the
- Initiator) currently in place on the file. If the value of the
- <requested access> parameter is not consistent with either <access
- control>, <permitted actions>, or concurrency controls in place, then
- the <F-SELECT> or <F-CREATE> must be rejected.
-
- <requested access> is consistent with <access control> if, for each
- action requested, that action either requires no password, or the
- required password has been specified on the <F-SELECT request> or <F-
- CREATE request>.
-
- <requested access> is consistent with <permitted actions> if, for each
- action requested, that action is allowed by the <permitted actions>
- file attribute.
-
- <requested access> is consistent with <concurrency control> requested
- on the <F-SELECT> or <F-CREATE> if, for each action requested, that
- action has not been specified as 'not required' or 'no access' in the
- <concurrency control> parameter.
-
- <requested access> is consistent with concurrency controls in place on
- the file if for each action requested no other accessor of the file
- has set the concurrency control for that action to either 'exclusive'
- or 'no access'.
-
- 6.16 SECURITY
-
- 6.16.1 Initiator Identity and Filestore Password
-
- The <initiator identity> and <filestore password> parameters for
- an implementation acting as an Initiator are supported. These
- parameters are optional for an implementation acting as a
- Responder.
-
-
-
- The syntax of <initiator identity> and <filestore password> is
- system-dependent. <initiator identity> and <filestore password>
- will represent account information on the local system, which
- may be different from the <account> parameter.
-
- 6.16.2 Access Passwords
-
- The <access passwords> and <create password> parameters for an
- implementation acting as an Initiator are supported if the
- Security Group of attributes is supported. These parameters for
- an implementation acting as a Responder are optionally supported
- if the Security Group is supported.
-
-
-
-
- 6.16.3 Implementation Responsibilities
-
- It is the responsibility of each local system to provide security
- for its own real filestore. Encryption of passwords will not be
- done by FTAM.
-
- A user of the file service must be known by the Responder.
- "Known" is defined by the local Filestore, and is dependent on
- the level of security provided by the local Filestore.
-
-
- 6.17 REQUIREMENT FOR CONFORMANT IMPLEMENTATIONS
-
- This section gives the criteria to be satisfied by every
- implementation of FTAM that conforms to these Agreements.
-
- Conformance to these Agreements is stated in terms of the different
- roles occupied by FTAM implementations. The interoperability of
- certain configurations of these roles motivates this approach.
- Interoperable configurations of these roles are given in section
- 6.17.1.
-
- The only function provided by every conformant implementation is the
- transfer of unstructured binary files in their entirety. It must be
- recognized that such simple transfer, while commonly understood and
- generally important, will not support all applications of FTAM.
- Section 6.18 defines Implementation Profiles of FTAM services and
- protocol that can provide other specific functions. Those other
- functions exploit the access and management capabilities of FTAM. The
- unconstrained service class (with appropriately chosen functional
- units) can be used to provide the functions of any of the
- Implementation Profiles. Users of FTAM must consider carefully what
- functions they require. They must examine all the Implementation
- Profiles and select according to their needs.
-
- Implementation conforming to these Agreements require adherence to the
- General Agreements in sections 6.5 through 6.16 of these Agreements.
-
-
- 6.17.1 Interoperable Configurations
-
- Any implementation conforming to this specification must be able
- to act in at least one of the following role combinations:
-
- 1. initiator and receiver,
-
- 2. initiator and sender,
-
- 3. responder and sender,
-
- 4. responder and receiver.
-
- Minimal implementations of combination 1 will interoperate with
- minimal implementations of combination 3. Minimal
- implementations of combination 2 will interoperate with minimal
- implementations of combination 4.
-
- Any implementations of roles l and 3 will be able to interoperate
- at the intersection of their capabilities (which will be at least
- the minimal capabilities described in sections 6.17.3 to 6.17.8).
- Any implementations of roles 2 and 4 will be able to interoperate
- at the intersection of their capabilities (which will be at least
- the minimal capabilities described in sections 6.17.3 to 6.17.8).
-
- These role combinations and this interoperability are shown in
- Table 6.5 below.
-
- Table 6.5 Interoperable configurations
-
- ZDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD?
- 3 : Initiator 3 Responder 3
- 3 GDDDDDDDDDBDDDDDDDDDDDDEDDDDDDDDDBDDDDDDDDDDDDD4
- 3 : sender 3 receiver 3 sender 3 receiver 3
- 3MMMMMMMMMMMQMMMMMMMMMMMNMMMMMMMMMXMMMMMMMMMMMMXMMMMMMMMMXMMMMMMMMMMMMM3
- 3 3 sender : 3 3 3 x 3
- 3 Initiator CDDDDDDDDDDDWDDDDDDDDDEDDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDD3
- 3 3 receiver : 3 3 x 3 3
- CDDDDDDDDDDDEDDDDDDDDDDDWDDDDDDDDDEDDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDD4
- 3 3 sender : 3 x 3 3 3
- 3 Responder CDDDDDDDDDDDWDDDDDDDDDEDDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDD4
- 3 3 receiver : x 3 3 3 3
- 3 3 : 3 3 3 3
- @DDDDDDDDDDDADDDDDDDDDDDPDDDDDDDDDADDDDDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDY
-
-
- 6.17.2 Relationship to ISO 8571--The FTAM Standard
-
- Any implementation in conformance to ISO 8571 (as defined in ISO
- 8571-4, clause 22 (Conformance)), in addition to the
- implementation of the minimal protocols and roles enumerated in
- sections 6.17.3 to 6.17.8, is considered to be in conformance
- with these Agreements. Any implementation violating any of the
- conformance statements in ISO 8571-4 is considered to be in
- violation of these Agreements.
-
-
- 6.17.3 Requirements for Document Type Support
-
- The document type FTAM-3 shall be supported for purposes of
- transfer and storage. The details regarding support for FTAM-3
- in the FTAM dialogue are given in section 6.10.
-
- Support of document types other than FTAM-3 is not required for
- conformant implementations. Support for document types described
- in these Agreements also entails support for:
-
- o the semantics given in their description and further
- qualified in 6.10
-
- o the preferred transfer syntax "Basic Encoding of a
- single ASN.1 type"
-
-
- 6.17.4 Initiators
-
- Every implementation of an FTAM Initiator shall support:
-
- o the kernel protocol and its mandatory parameters with
- minimum ranges [Minimum required ranges are specified
- in section 6.17.8.],
-
- o the grouping protocol and the <threshold> parameter
- with a value of at least 2 for use in the file transfer
- class,
-
- o at least one of the read or write protocols [Specific
- conformance for reading and writing is defined in
- sections 6.17.6 and 6.17.7.],
-
- and support the applicable procedures defined in ISO 8571-4
- clauses 8.1 (FTAM regime establishment), 8.2 (FTAM regime
- termination), 8.3 (File selection), 8.4 (File deselection), 8.9
- (File open), 8.10 (File close), 8.11 (Begin group), 8.12 (End
- group), and 10 (File general actions). To support the above
- protocols and procedures the implementation shall always support
- the kernel functional unit and additionally shall be able to:
-
- o request the grouping and at least one of the read or
- write functional units,
-
- o request the file transfer class with the <service
- class> parameter,
-
- o request the document type FTAM-3 using the <document
- type name> form of the <contents type> parameter,
-
- o request the <FTAM quality of service> parameter with
- value 0 and accept in all cases the returned value 0,
- and
-
- o request a <communication quality of service> consistent
- with the transport definition in these Agreements
-
- as part of the Filestore initialization procedures in ISO 8571-4
- clause 8.1, FTAM regime establishment.
-
- Initiators must be able to operate under all circumstances if the
- above minimum values are successfully negotiated and returned on
- an <F-INITIALIZE response> PDU. Initiators must be able to
- operate with any downward negotiation of requested parameter
- values as described in the standard.
-
- Should the supporting services break down, such that FTAM
- communication is impossible, the FTAM protocol machine shall
- notify the user with an <F-P-ABORT indication> and <diagnostic>
- value with identifier 1011, as well as any known <further
- details>.
-
- Note: Interworking may not be possible between Initiators not
- supporting attributes of the Storage Group and Security Group,
- and Responders requiring these attributes to be used.
-
-
- 6.17.5 Responders
-
- Every implementation of an FTAM Responder shall support:
-
- o the kernel protocol and its mandatory parameters with
- minimum ranges [Minimum required ranges are specified
- in section 6.17.8.],
-
- o the grouping protocol and the <threshold> parameter
- with a value of at least 2 for use in the file transfer
- class,
-
- o at least one of the read or write protocols [Specific
- conformance for reading and writing is defined in
- sections 6.17.6 and 6.17.7],
-
- and support the applicable procedures, defined in ISO 8571-4
- clauses 9.1 (FTAM regime establishment), 9.2 (FTAM regime
- termination), 9.3 (File selection), 9.4 (File deselection), 9.9
- (File open), 9.10 (File close), 9.11 (Begin group), 9.12 (End
- group), and 10 (File general actions). To support the above
- protocols and procedures the implementation shall always support
- the kernel functional unit and additionally shall be able to:
-
- o accept requests for the grouping and at least one of
- the read or write functional units,
-
- o accept requests for the file transfer class with the
- <service class> parameter,
-
- o accept the document type FTAM-3 using the <document
- type name> form of the <contents type> parameter,
-
- o accept requests for an <FTAM quality of service>
- parameter with any value but may respond with the value
- 0, and
-
- o accept requests for a <communication quality of
- service> consistent with the transport definition in
- these agreements
-
- as part of the filestore initialization procedures in ISO 8571-4
- clause 9.1, FTAM regime establishment.
-
- Responders must be able to operate under all circumstances if the
- above minimum values are requested on an <F-INITIALIZE request>
- PDU. Responders must not negotiate upward in the sense described
- in the standard.
-
- Responders must complete each action requested and supported in a
- manner consistent with its description in ISO 8571-2 clauses 10
- (Actions on complete files) and 11 (Actions for file access), and
- must interpret each supported attribute in a manner consistent
- with its definition in ISO 8571-2 clause 12 (File attributes).
-
- Under circumstances where actions cannot be carried out either as
- requested or consistently with ISO 8571-2 clause 10 (Actions on
- complete files) and 12 (Actions for file access), the Responder
- must return at least one diagnostic indicating:
-
- o if the failure was due to either a protocol or
- Filestore failure, and then:
-
- -- precisely which action failed,
- -- at least one of the parameters that could not be
- accommodated with the diagnostic type indicating
- at least the degree of failure, as given by the
- action and state result parameter, or
-
- o that the failure was due to unforeseen system shutdown.
-
- Should the supporting services break down, such that FTAM
- communication is impossible, the FTAM protocol machine shall
- notify the user with an <F-P-ABORT indication> and <diagnostic>
- with identifier 1011, as well as inform the user of any known
- <further details>.
-
-
- 6.17.6 Senders
-
- Every implementation of an FTAM sender shall support the read
- functional unit as Responder or the write functional unit as
- Initiator, and support the applicable procedures defined in ISO
- 8571-4 clauses 11 (State of the bulk data transfer activity), 12
- (Bulk data transfer protocol data units), 15 (Bulk data transfer
- sending entity actions), 17.1 (Discarding), and 17.2 (Cancel).
-
- To support those procedures the implementation shall be able to
- send files of the document type FTAM-3 and shall be able to send
- them as user data in PPDUs in blocks of up to 7168 octets.
-
-
- 6.17.6.1 Initiator Senders
-
- Every implementation of an FTAM sender which is also an FTAM
- Initiator shall support:
-
- o the write functional unit and protocol, and
-
- o for the document type FTAM-3 the following bulk
- data transfer specification parameters:
-
- FADU operation replace
- FADU identity first
-
- and support the applicable procedures, defined in ISO 8571-4
- clause 13 (Bulk data transfer initiating entity actions).
-
-
- 6.17.6.2 Responder Senders
-
- Every implementation of an FTAM sender which is also an FTAM
- Responder shall support:
-
- o the read functional unit and protocol, and
-
- o for the document type FTAM-3 the following bulk
- data transfer specification parameters:
-
- FADU identity first
- Access context UA
-
- and support the applicable procedures, defined in ISO 8571-4
- clause 14 (Bulk data transfer responding entity actions).
-
-
- 6.17.7 Receivers
-
- Every implementation of an FTAM receiver shall support the read
- functional unit as Initiator or the write functional unit as
- Responder, and support the applicable procedures, defined in ISO
- 8571-4 clauses 11 (State of the bulk data transfer activity), 12
- (Bulk data transfer protocol data units), 16 (Bulk data transfer
- receiving entity actions), 17.1 (Discarding), and 17.2 (Cancel).
-
- To support those procedures the implementation shall be able to
- receive files of the document type FTAM-3 and shall be able to
- receive them as user data in PPDUs in blocks of at least 7168
- octets.
-
-
- 6.17.7.1 Initiator Receivers
-
- Every implementation of an FTAM receiver which is also an
- FTAM Initiator shall support:
-
- o the read functional unit and protocol, and
-
- o for the document type FTAM-3 the following bulk
- data transfer specification parameters:
-
- FADU identity first
- Access context UA
-
- and support the applicable procedures, defined in ISO 8571-4
- clause 13 (Bulk data transfer initiating entity actions).
-
-
- 6.17.7.2 Responder Receivers
-
- Every implementation of an FTAM receiver which is also an
- FTAM Responder shall support:
-
- o the write functional unit and protocol, and
-
- o for the document type FTAM-3 the following bulk
- data transfer specification parameters:
-
- FADU operation replace
- FADU identity first
-
- and support the applicable procedures, defined in ISO 8571-4
- clause 14 (Bulk data transfer responding entity actions).
-
-
- 6.17.8 Minimum Ranges
-
- Any implementation of any conformant FTAM configuration shall be
- able to receive and meaningfully process all mandatory parameters
- for all functional units supported as well as the <diagnostic>
- parameter within at least the minimum ranges of values given in
- Table 6.6. A conforming implementation may support a wider range
- of values for any parameter.
-
-
- Table 6.6 Required minimal parameter support
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Parameter Minimum Range 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3general diagnostic Values as specified in ISO 8571-3 Annex A 3
- 3 (Diagnostic parameter values) Tables 44, 3
- 3 45 and 46 which correspond directly to 3
- 3 mandatory parameters. 3
- 3 action result All values. 3
- 3 state result All values. 3
- 3 3
- 3F_INITIALIZE 3
- 3 3
- 3 functional units1 'read' (for initiator/receivers and 3
- 3 responder/senders) and 'grouping' 3
- 3 or 3
- 3 'write' (for initiator/senders and 3
- 3 responder/receivers) and 'grouping' 3
- 3presentation context management2 'Not required.' 3
- 3 all others As specified in sections 6.17.4 and 3
- 3 6.17.5 above. 3
- 3 3
- 3 3
- 3F_SELECT 3
- 3 attributes Only <filename> is used with a minimum 3
- 3 supportable length of 8 characters. Any 3
- 3 other attribute supported for other 3
- 3 services must have minimum supported 3
- 3 lengths as in ISO 8571-2 clause 15 3
- 3 (Minimum attribute ranges) Table 2. 3
- 3 3
- 3 requested access 'read' for initiator/receivers 3
- 3 'read' for responder/senders 3
- 3 'replace' for initiator/senders 3
- 3 'replace' for responder/receivers 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 6.6 Required minimal parameter support, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Parameter Minimum Range 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3F_OPEN 3
- 3 processing mode 'read' for initiator/receivers 3
- 3 'read' for responder/senders 3
- 3 'replace' for initiator/senders 3
- 3 'replace' for responder/receivers 3
- 3 3
- 3 contents type 'FTAM-3' 3
- 3 3
- 3F_READ 3
- 3 FADU identity 'first' 3
- 3 access context 'UA' 3
- 3F_WRITE 3
- 3 FADU operation 'read' for initiator/receivers 3
- 3 'read' for responder/senders 3
- 3 'replace' for initiator/senders 3
- 3 'replace' for responder/receivers 3
- 3 3
- 3 FADU identity 'first' 3
- 3 3
- 3F_BEGIN_GROUP 3
- 3 3
- 3 threshold3 For file transfer (a minimal required 3
- 3 function) 2. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- For any other supported parameters, minimum ranges are taken from
- the minimum ranges for the attribute corresponding to each as in
- ISO 8571-2 Table 4.
-
- DDDDDDDDDDDDDDD
- Notes:
- 1. The parameters, functional units, and presentation context
- management are not ordered, so "minimum value" cannot be
- formally defined. The above values are those required for
- conformance to these Agreements but no value conformant to
- ISO 8571 for use in other applications is regarded to be in
- violation of these Agreements.
-
- 2. Other functional units (and service classes) for defined
- implementations may also be valid provided that they are
- implemented in accordance with these Agreements,
- specifically section 6.17.8.
-
- 3. Every implementation must support the <threshold> value 2 to
- provide the basic required function of file transfer; any
- other value in other applications is acceptable.
-
-
- 6.17.9 Use of Lower Layer Services
-
- o Support for the Presentation Context Management
- functional unit is not required.
-
- o Implementations will support the Session, Presentation,
- and ACSE requirements as stated in section 5.
-
- Note: Implementation of the Session Resynchronize and the Minor
- Synchronize functional units is highly recommended, since the F-
- CANCEL service may be less effective when mapped to S-DATA.
-
-
- 6.18 IMPLEMENTATION PROFILES
-
- This section defines Implementation Profiles for the specific
- functions of:
-
- o File Transfer
- o File Access
- o File Management.
-
- Those definitions are expressed in terms of:
-
- o Document Types
- o Attributes
- o Service Classes (both service elements and their
- parameters).
-
- This by no means defines all possible Implementation Profiles.
-
- The following Implementation Profiles are defined:
-
- T1: Simple File Transfer
- T2: Positional File Transfer
- T3: Full File Transfer
- A1: Simple File Access
- A2: Full File Access
- M1: Management.
-
- Implementation Agreements have been reached for the following service
- classes. Note that any given implementation may support more than one
- service class.
-
- o File Transfer
- o File Access
- o File Management
- o Unconstrained
- o File Transfer and Management
-
- Support of an Implementation Profile requires adherence to:
-
- 1. corresponding definition in 8571-3 clause 8 and any related
- procedures in 8571-4 clause 8-17,
-
- 2. requirements given in sections 6.5-6.18 of these Agreements, and
-
- 3. requirements for parameter and attribute support as defined in
- section 6.17.8.
-
- 6.18.1 General Requirements for the Defined Implementation
- Profiles
-
-
- o Implementations will be able to act either as Initiator or
- Responder or both.
-
- o Implementations must support diagnostics as described in
- section 6.13 of these Agreements.
-
- o Implementations that support the file access service class
- will support access to sequential files. Support of
- sequential files entails hierarchy of depth and arc length
- equal to 1. Other hierarchy depth and arc lengths are not
- precluded by these agreements.
-
-
- 6.18.2 Intentionally Left Empty
-
-
- 6.18.3 Document Type Requirements for the Defined
- Implementation Profiles
-
- Implementations conformant to Implementation Profiles defined in
- Table 6.7 will support the following document types with the
- caveats and procedures given. Those document types are defined
- in Appendix 6A and section 6.10 of these Agreements, and in ISO
- 8571-2.
-
- o FTAM-1
-
- o FTAM-2
-
- o FTAM-3
-
- o NBS-6
-
- o NBS-7
-
- Note: Support of this document type entails the
- naming of FADUs by their position in
- preorder traversal.
-
- Caveat: Other methods of naming FADUs depend on the
- system, application, and specific file, and
- as such are not described here.
- o NBS-8
-
- o NBS-9
-
- Support for any document type requires the ability to transfer
- and store the abstract syntax given in its definition. These
- Agreements do not specify techniques or formats for storage.
-
- Caveat: Specific abstract syntaxes for the parameterized
- document types NBS-6,7,8 are not specified in these
- Agreements.
-
- Any document type supported must be identifiable by its document
- type name as given in ISO 8571-2 and in Appendix 6A of these
- Agreements and, where defined, the parameterization scheme given
- in section 6.10 of these Agreements.
-
- For conformance to NBS-9 a Responder is only required to return
- the <filename> attribute, subject to local security and access
- control. All other requested attributes need not be returned.
-
- Systems supporting the NBS-9 document type shall make available
- an NBS-9 document called 'DIRLIS'. This document can be used to
- obtain a listing of files and their associated attributes from a
- remote Filestore.
-
- File security issues related to NBS-9 are subject to the security
- agreements outlined in section 6.16.
-
-
- 6.18.4 Parameters for the Defined Implementation Profiles
-
- o
-
- o
-
- o Implementations will support the <contents type list>
- parameter on the <F-INITIALIZE> service element. The
- initiating service must supply a value for this
- parameter.
-
- o Implementations will support the <diagnostic> parameter
- as stated in section 6.13 of these Agreements.
-
- o The <initiator identity> parameter is supported. Use
- must be consistent with section 6.16 of these
- Agreements.
-
- o Implementations are not precluded from using other
- parameters for security and/or accounting. Responders
- must state the semantics applying to <account> and
- <charging> parameters. The Responder's minimum
- implementation is to accept but ignore the <account>.
- and to return a <charging> value of zero.
-
-
- 6.18.5 Parameter Ranges for the Defined Implementation
- Profiles
-
- Parameter ranges for Implementations Profiles are as stated for
- primitive data types in section 6.10 of these agreements.
-
-
- 6.18.6 File Attribute Support for Implementations
-
- Implementations of the Implementation Profiles will support file
- attributes or attribute groups in the following ways.
-
- o mandatory
- This feature is mandatory in the ISO 8571-2
- standard and shall therefore be implemented by all
- implementations claiming conformance to these
- Agreements.
-
- o supported
- This feature shall be implemented by all
- implementations claiming conformance to these
- Agreements (for attributes, this implies that at
- least the minimum range of attribute values, as
- defined in ISO 8571-2 clause 15, shall be
- supported). Conformant implementations shall also
- be able to interwork with other implementations
- that do not support this feature by negotiating
- out the corresponding features.
-
- o optionally supported
- Implementations claiming conformance to these
- Agreements may or may not implement this feature
- (for attributes, this implies that at least either
- the minimum range of attribute values, as defined
- in ISO 8571-2 clause 15, shall be supported or
- that the 'no value available' result shall be
- supplied). If an attribute group with a support
- level of 'optionally supported' is chosen to be
- supported, then all the attributes of this group
- that are classified as 'mandatory' or 'supported'
- shall be supported.
-
- o not supported
- This feature is outside the scope of these
- Agreements.
-
-
- Kernel Group mandatory
-
- o Filename mandatory
- o Permitted Actions mandatory
- o Contents Type mandatory
-
- Storage Group optionally supported
-
- o Storage Account optionally supported
- o Date and Time of Creation optionally supported
- o Date and Time of Last Modification optionally supported
- o Date and Time of Last Read Access optionally supported
- o Date and Time of Last Attribute Modification optionally supported
- o Identity of Creator optionally supported
- o Identity of Last Modifier optionally supported
- o Identity of Last Reader optionally supported
- o Identity of Last Attribute Modifier optionally supported
- o File Availability supported
- o Filesize supported
- o Future Filesize optionally supported
-
- Security Group optionally supported
-
- o Access Control supported
- o Legal Qualifications optionally supported
-
- Private Group not supported
-
- Table 6.7 Implementation profile support requirements
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3 Service Class 3
- 3 Functional Unit 3 T M A T&M UNCST 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 Kernel 3 T1,T2,T33 M1 3 A1,A2 3 3 3
- 3 Read (See note 3.) 3 T1,T2,T33 3 A1,A2 3 3 3
- 3 3 3 3 3 3 3
- 3 Write (See note 3.) 3 T1,T2,T33 3 A1,A2 3 3 3
- 3 3 3 3 3 3 3
- 3 Limited File Mgmnt. 3SeeNote 63 M1 3SeeNote 63 See 3 See 3
- 3 Enhanced File Mgmnt. 3 3 M1 3 3 3 3
- 3 Grouping 3 T1,T2,T33 M1 3 3 3 3
- 3 File Access 3 3 3 A1,A2 3 3 3
- 3 3 3 3 3 3 3
- 3 Document Types 3 3 3 3 3 3
- 3 3 3 3 3 3 3
- 3 FTAM-1 3 T1,T2,T33 [M1] 3 A1,A2 3 3 3
- 3 FTAM-2 3 T2,T3 3 [M1] 3 A1,A2 3 3 3
- 3 FTAM-3 3 T1,T2,T33 [M1] 3 A1,A2 3 Note 3 Note 3
- 3 3 3 3 3 3 3
- 3 NBS-6 3 [T2],T3 3 [M1] 3 [A1],A23 4 3 5 3
- 3 3 3 3 3 3 3
- 3 NBS-7 3 [T2],T3 3 [M1] 3 [A1],A23 3 3
- 3 3 3 3 3 3 3
- 3 NBS-8 3 T3 3 [M1] 3 A2 3 3 3
- 3 3 3 3 3 3 3
- 3 NBS-9 3[T1],[T2]3 [M1] 3 3 3 3
- 3 3[T3] 3 3 3 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDY
-
- Notes: to 6.18.3 and Table 6.7
-
- 1. The Management Implementation Profile is only to be implemented in
- conjunction with one of the Transfer or Access Profiles.
-
- 2. Profile T2 is subset of T3. A1 and T1 are subsets of A2 and T2,
- respectively.
-
- 3. Profiles T1, T2, and T3 require the support of read and/or write
- functional units.
-
- 4. Support of the <File Transfer and Management> service class is
- optional. If an implementation is capable of supporting
- Implementation Profile M1 and one of the T-Implementation Profiles,
- the Initiator may choose to request the <File Transfer and Management>
- service class. Any implementation so doing must be prepared for the
- possibility of rejection of the request by the Responder.
-
- Support of the <File Transfer and Management> service class is
- optional. The rules for including it in a request and for the
- response to it are as given in ISO 8571-3, clause 10.1. Any
- implementation including TM in the request must be prepared for the
- possibility that it might be removed from the response.
-
- 5. The support of the <Unconstrained> service class is optional. There
- are no constraints on this service class beyond those of ISO 8571.
-
- 6. Limited File Management is not required for the T- and A-
- Implementation Profiles, but very often it will be a user request to
- have limited file management functionality available together with
- file transfer and file access functions. So Limited File Management
- may be added as an option to the T- and A- Implementation Profiles.
-
- 7. [] in Table 6.7 specifies that the document type is optional for the
- respective Implementation Profile. For M1 the support level depends
- on the T- or A- Implementation Profile, in conjunction with which M1
- is implemented.
-
-
- 6.19 PROVISION OF SPECIFIC FUNCTION
-
-
- 6.19.1 Implementation Profile T1: Simple File Transfer
-
- Implementation Profile T1 provides the function of transferring
- entire files at the external file service level for files with an
- unstructured constraint set. This includes support of the
- document types:
-
- o FTAM-1 "ISO FTAM unstructured text"
- o FTAM-3 "ISO FTAM unstructured binary"
- o NBS-9 "NBS-9 file directory file" (optional)
-
- This Implementation Profile supports file transfer and not file
- access, that is, the ability to:
-
- o read a complete file
-
- and/or
-
- o write (replace, extend) to a file.
-
-
- 6.19.2 Implementation Profile T2: Positional File Transfer
-
- Implementation Profile T2 provides the function of transferring
- files at the external file service level for files with an
- unstructured or flat constraint set. This includes support of
- the document types:
-
- o FTAM-1 "ISO FTAM unstructured text"
- o FTAM-2 "ISO FTAM sequential text"
- o FTAM-3 "ISO FTAM unstructured binary"
- o NBS-6 "NBS-6 FTAM sequential file" (optional)
- o NBS-7 "NBS-7 FTAM random access file" (optional)
- o NBS-9 "NBS-9 file directory file" (optional)
-
- This Implementation Profile supports file transfer and not file
- access, that is, the ability to:
-
- o read a complete file or a single FADU which is
- identified by position
-
- and/or
-
- o write (replace, extend, insert depending on constraint
- set and document type) to a file or an FADU.
-
- This Implementation Profile is upwardly compatible to T1 for the
- transfer of unstructured files.
-
-
- 6.19.3 Implementation Profile T3: Full File Transfer
-
- Implementation Profile T3 provides the function of transferring
- files at the external file service level for files with an
- unstructured, flat or general hierarchical constraint set. This
- includes support of the document types:
-
- o FTAM-1 "ISO FTAM unstructured text"
- o FTAM-2 "ISO FTAM sequential text"
- o FTAM-3 "ISO FTAM unstructured binary"
- o NBS-6 "NBS-6 FTAM sequential file"
- o NBS-7 "NBS-7 FTAM random access file"
- o NBS-8 "NBS-8 FTAM indexed file"
- o NBS-9 "NBS-9 file directory file" (optional)
-
- This Implementation Profile supports file transfer and not file
- access, that is, the ability to:
-
- o read a complete file or a single FADU which is
- identified by key or by position
-
- and/or
-
- o write (replace, extend, insert depending on constraint
- set and document type) to a file or an FADU.
-
- This Implementation Profile is upwardly compatible to T1 for the
- transfer of unstructured files.
-
-
- 6.19.4 Implementation Profile A1: Simple File Access
-
- Implementation Profile A1 provides the function of transfer of
- and access to files with unstructured or flat constraint sets at
- the external file service level. This includes support of the
- document types:
-
- o FTAM-1 "ISO FTAM unstructured text"
- o FTAM-2 "ISO FTAM sequential text"
- o FTAM-3 "ISO FTAM unstructured binary"
- o NBS-6 "NBS-6 FTAM sequential file" (optional)
- o NBS-7 "NBS-7 FTAM random access file" (optional)
-
-
- This Implementation Profile supports file transfer and file
- access, that is the ability to:
-
- o read a complete file or FADUs which are identified by
- position,
-
- o write (replace, extend, insert depending on constraint
- set and document type) to a file or an FADU,
-
- o locate and erase within files.
-
-
-
- 6.19.5 Implementation Profile A2: Full File Access
-
- Implementation Profile A2 provides the function of transfer of
- and access to files with unstructured or flat constraint sets at
- the external file service level. This includes support of the
- document types:
-
- o FTAM-1 "ISO FTAM unstructured text"
- o FTAM-2 "ISO FTAM sequential text"
- o FTAM-3 "ISO FTAM unstructured binary"
- o NBS-6 "NBS-6 FTAM sequential file"
- o NBS-7 "NBS-7 FTAM random access file"
- o NBS-8 "NBS-8 FTAM indexed file"
-
- This Implementation Profile supports file transfer and file
- access, that is, the ability to:
-
- o read from a complete file, or from a series of FADUs
- which are identified by key or by position,
-
- o write (replace, extend, insert depending on constraint
- set and document type) to a file or an FADU,
-
- o locate and erase within files.
-
-
-
- 6.19.6 Implementation Profile M1: Management
-
- Implementation Profile M1 provides the function for an Initiator
- to manage the files within the Virtual Filestore, to which access
- is provided by the Responder. Management includes the services
- of:
-
- o creating a file
- o deleting a file
- o reading attributes of a file
- o changing attributes of a file.
-
-
- 6.20 HARMONIZATION
-
- The Implementation Profiles for File Transfer, File Access and
- Management correspond to the Profiles of SPAG (Standards Promotion and
- Application Group) in Europe, so that interworking will be possible.
- Those Profiles are described in the 'Guide to the Use of Standards'
- (GUS); they are the basis for the Functional Standards as defined by
- CEN/CENELEC (Comite Europeenne de Normalization).
-
- Table 6.8 Implementation Profiles (NBS) and Profiles (SPAG/CEN-CLC)
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Implementation Profile SPAG/CEN-CLC 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3 3
- 3 T1 3 A/111 3
- 3 T2 3 A/112 3
- 3 T3 3 A/113 3
- 3 A1 3 A/122 3
- 3 A2 3 A/123 3
- 3 M1 3 A/13 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDY
- 6.21 APPENDIX A: FTAM DOCUMENT TYPES
-
-
- Part 1: Document Types
- Part 2: Constraint Sets
- Part 3: Abstract Syntaxes
- Part 4: Intentionally Left Empty
- Part 1: Document Types
-
- NBS-6 Sequential file document type
-
- 1. Entry Number: NBS-6
-
- 2. Information objects
- Table 6.9 Information objects in NBS-6
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 document type name : {iso identified-organization icd (9999) 3
- 3 : organization-code (1) document 3
- 3 : type (5) sequential (6)} 3
- 3 : "NBS-6 FTAM sequential file" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 abstract syntax names: : {iso identified-organization icd (9999) 3
- 3 a) name for asname1 : organization-code (1) abstract- 3
- 3 : syntax (2) nbs-as1 (1)} 3
- 3 : "NBS abstract syntax AS1" 3
- 3 b) name for asname2 : {iso standard 8571 abstract-syntax(2) ftam- 3
- 3 : fadu (2)} 3
- 3 : "FTAM FADU" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)3
- 3 : } "Basic Encoding of a single ASN.1 type" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3parameter syntax: 3
- 3 PARAMETERS ::= SEQUENCE OF CHOICE {Parameter0, Parameter1, Parameter2} 3
- 3 Parameter0 ::= universal-class-number-0 [0] INTEGER {univer-time (23), 3
- 3 gen-time (24), 3
- 3 boolean (1), 3
- 3 null (5) } 3
- 3 Parameter1 ::= [1] SEQUENCE { 3
- 3 universal-class-number-1 INTEGER { int (2), 3
- 3 bit (3), 3
- 3 ia5 (22), 3
- 3 graphic (25), 3
- 3 general (27), 3
- 3 octet (4)}, 3
- 3 string-length INTEGER } 3
- 3 Parameter2 ::= [2] SEQUENCE { 3
- 3 private-class-number INTEGER {float (0)}, 3
- 3 length-1 INTEGER, 3
- 3 length-2 INTEGER } 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 file model : {iso standard 8571 file-model (3) 3
- 3 : hierarchical (1)} 3
- 3 : "FTAM hierarchical file model" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 constraint set : {iso standard 8571 constraint-set (4) 3
- 3 : sequential-flat (2)} 3
- 3 : "FTAM sequential flat constraint set" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 file contents: 3
- 3 Datatype1 ::= PrimType -- as defined in Annex 6 A, Part 3 3
- 3 Datatype2 ::= CHOICE { Node-Descriptor-Data-Element, 3
- 3 Enter-Subtree-Data-Element , Exit- 3
- 3 Subtree-Data-Element} 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- 3. Scope and field of application
-
- The document type defines the contents of a file for storage, for
- transfer and access by FTAM.
-
- Note: Storage refers to apparent storage within the Virtual Filestore.
-
- 4. References
-
- ISO 8571, Information Processing Systems - Open Systems
- Interconnection - File Transfer, Access and Management
-
- 5. Definitions
-
- This definition makes use of the terms data element, data unit and
- file access data unit as defined in ISO 8571-1.
-
- 6. Abbreviations
-
- FTAM File Transfer, Access and Management
-
- 7. Document semantics
-
- The document consists of zero, one or more file access data units,
- each of which consists of zero, one or more data elements. The order
- of each of these elements is significant.
-
- The document structure takes any of the forms allowed by the FTAM
- hierarchical file model as constrained by the sequential flat
- constraint set (see Table 6.9) These definitions appear in ISO 8571-
- 2. As additional constraints FADU identity will be limited to
- 'begin', 'end', 'first' and 'next'.
-
- For a specific file the number of data elements in a data unit is
- given by the parameters. Each data element is a data type from the
- set of primitive data types defined in the Annex 6.A, Part 3 of this
- document. Each data unit contains the same data element types in the
- same order as all other data units. These types are determined by the
- parameters 0 through 2.
-
- Note: The string length values are the actual number of characters
- from the specified character set, they do not include any escape
- sequences or overhead from the encoding.
-
- 8. Abstract syntactic structure
-
- The abstract syntactic structure of the document is a hierarchically
- structured file as defined in the ASN.1 module ISO8571-FADU in ISO
- 8571, in which each of the file access data units has the abstract
- syntactic structure of NBS-AS1 as defined by the parameters.
-
- 9. Definition of transfer
-
- 9.1 Datatype definitions
-
- The file consists of data values which are of either
-
- a) Datatype1 defined in Table 6.9, where the PrimType in
- the datatype is given by the NBS-AS1 definition; or
-
- b) Datatype2 defined in Table 6.9, the ASN.1 datatype
- declared as "Data-Element" in the ASN.1 module ISO8571-
- FADU.
-
- 9.2 Presentation data values
-
- The document is transferred as a series of presentation data
- values, each of which is either
-
- a) one value of the ASN.1 datatype "Datatype1", carrying
- one of the data elements from the document. All values
- are transmitted in the same (but any ) presentation
- context defined to support the abstract syntax name
- "asname1" or
-
- b) a value of "Datatype2". All values are transmitted in
- the same (but any) presentation context defined to
- support the abstract syntax name "asname2".
-
- Notes:
-
- 1. Specific carrier standards may impose additional constraints
- on the presentation context to be used, where the above
- permits a choice
- 2. Any document type defined in this entry either makes no use
- of Datatype2, or starts with a Datatype2 transmission.
-
- Boundaries between presentation data values in the same
- presentation context, and boundaries between P-DATA primitives,
- are chosen locally by the sending entity at the time of
- transmission, and carry no semantics of the document type.
- Receivers which support this document type shall accept a
- document with any of the permitted transfer options (e.g.
- document type parameters and transfer syntaxes).
-
- 9.3 Sequence of presentation data values
-
- The sequence of presentation data values of type a) and the
- sequence of presentation data values of types a) and b) is the
- same as the sequence of data elements within a Data Unit, and
- Data Units in the hierarchical structure, when flattened
- according to the definition of the hierarchical file model in ISO
- 8571-2.
-
- 10. Transfer syntax
-
- An implementation supporting this document type shall support the
- transfer syntax generation rules named in Table 6.9 for all
- presentation data values transferred. An implementation may
- optionally support other named transfer syntaxes.
-
- 11. ASE specific specifications for FTAM
-
- 11.1 Simplification and relaxation
-
- 11.1.1 Structural simplification
-
- This simplification loses information.
-
- The document type NBS-6 may be simplified to the document type
- FTAM-3 (allowed only when reading the file). The octet
- representation of the transferred data is unpredictable. It will
- usually correspond to the data values as stored in the local Real
- Filestore of the Responder.
-
- 11.2 Access context selection
-
- A document of type NBS-6 may be accessed in any one of the access
- contexts defined in the sequential flat constraint set. The
- presentation data units transferred in each case are those
- derived from the structuring elements defined for that access
- context in ISO 8571-2.
-
- 11.3 The INSERT operation
-
- When the <INSERT> operation is applied at the end of file the
- transferred material shall be the series of FADUs which would be
- generated by reading any NBS-6 document with the same parameter
- values in access context FA.NBS-7 Random access file
-
- 1. Entry number: NBS-7
-
- 2. Information objects
- Table 6.10 Information objects in NBS-7
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 document type name : {iso identified-organization icd (9999) 3
- 3 : organization-code (1) document 3
- 3 : type (5) random-file (7)} 3
- 3 : "NBS-7 FTAM random access file"3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 abstract syntax names: : {iso identified-organization icd (9999) 3
- 3 a) name for asname1 : organization-code (1) abstract- 3
- 3 : syntax (2) nbs-as1 (1)} 3
- 3 : "NBS abstract syntax AS1" 3
- 3 b) name for asname2 : {iso standard 8571 abstract-syntax(2) ftam- 3
- 3 : fadu (2)} "FTAM FADU" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)3
- 3 : } "Basic Encoding of a single ASN.1 type"3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3parameter syntax: 3
- 3 PARAMETERS ::= SEQUENCE OF CHOICE {Parameter0, Parameter1, Parameter2} 3
- 3 Parameter0 ::= universal-class-number-0 [0] INTEGER {univer-time (23), 3
- 3 gen-time (24), 3
- 3 boolean (1), 3
- 3 null (5) } 3
- 3 Parameter1 ::= [1] SEQUENCE { 3
- 3 universal-class-number-1 INTEGER { int (2), 3
- 3 bit (3), 3
- 3 ia5 (22), 3
- 3 graphic (25), 3
- 3 general (27), 3
- 3 octet (4)}, 3
- 3 string-length INTEGER } 3
- 3 Parameter2 ::= [2] SEQUENCE { 3
- 3 private-class-number INTEGER {float (0)}, 3
- 3 length-1 INTEGER, 3
- 3 length-2 INTEGER } 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 file model : {iso standard 8571 file-model (3) 3
- 3 : hierarchical (1)} 3
- 3 : "FTAM hierarchical file model" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 constraint set : {iso identified-organization icd (9999) 3
- 3 : organization-code (1) constraint-set (4) nbs3
- 3 : -ordered flat (2)} 3
- 3 : "NBS ordered flat constraint set" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 file contents: 3
- 3 Datatype1 ::= PrimType -- as defined in Annex 6 A, Part 3 3
- 3 Datatype2 ::= CHOICE { Node-Descriptor-Data-Element, 3
- 3 Enter-Subtree-Data-Element } 3
- 3 Exit-Subtree-Data-Element } 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- 3. Scope and field of application
-
- The document type defines the contents of a file for storage, for
- transfer and access by FTAM.
-
- Note: Storage refers to apparent storage within the Virtual Filestore.
-
- 4. References
-
- ISO 8571, Information Processing Systems - Open Systems
- Interconnection -File Transfer, Access and Management
-
- 5. Definitions
-
- This definition makes use of the terms data element, data unit and
- file access data unit as defined in ISO 8571-1.
-
- 6. Abbreviations
-
- FTAM File Transfer, Access and Management
-
- 7. Document semantics
-
- The document consists of zero, one or more file access data units,
- each of which consists of zero, one or more data elements. The order
- of each of these elements is significant.
-
- The document structure takes any of the forms allowed by the FTAM
- hierarchical file model as constrained by the NBS-ordered-flat
- constraint set (see Table 6.10). These definitions appear in Appendix
- 6 A, Part 2 of this document.
-
- For a specific file the number of data elements in a data unit is
- given by the parameters. Each data element is a data type from the
- set of primitive data types defined in the Annex 6.A, Part 3 of this
- document. Each data unit contains the same data element types in the
- same order as all other data units. These types are determined by the
- parameters 0 through 2.
-
- Note: The string length values are the actual number of characters
- from the specified character set, they do not include any escape
- sequences or overhead from the encoding.
-
- 8. Abstract syntactic structure
-
- The abstract syntactic structure of the document is a hierarchically
- structured file as defined in the ASN.1 module ISO8571-FADU in ISO
- 8571, in which each of the file access data units has the abstract
- syntactic structure of NBS-AS1 as defined by the parameters.
-
-
-
- 9. Definition of transfer
-
- 9.1 Datatype definitions
-
- The file consists of data values which are of either
-
- a) Datatype1 defined in Table 6.10, where the PrimType in
- the datatype is given by the NBS-AS1 definition; or
-
- b) Datatype2 defined in Table 6.10, the ASN.1 datatype
- declared as "Data-Element" in the ASN.1 module ISO8571-
- FADU.
-
- 9.2 Presentation data values
-
- The document is transferred as a series of presentation data
- values, each of which is either
-
- a) one value of the ASN.1 datatype "Datatype1", carrying
- one of the data elements from the document. All values
- are transmitted in the same (but any ) presentation
- context defined to support the abstract syntax name
- "asname1" or
-
- b) a value of " Datatype2". All values are transmitted in
- the same (but any) presentation context defined to
- support the abstract syntax name " asname2".
-
- Notes:
-
- 1. Specific carrier standards may impose additional constraints
- on the presentation context to be used, where the above
- permits a choice
- 2. Any document type defined in this entry either makes no use
- of Datatype2, or starts with a Datatype2 transmission.
-
- Boundaries between presentation data values in the same
- presentation context, and boundaries between P-DATA primitives,
- are chosen locally by the sending entity at the time of
- transmission, and carry no semantics of the document type.
- Receivers which support this document type shall accept a
- document with any of the permitted transfer options (e.g.
- document type parameters and transfer syntaxes).
-
- 9.3 Sequence of presentation data values
-
- The sequence of presentation data values of type a) and the
- sequence of presentation data values of types a) and b) is the
- same as the sequence of data elements within a Data Unit, and
- Data Units in the hierarchical structure, when flattened
- according to the definition of the hierarchical file model in ISO
- 8571-2.
-
- 10. Transfer syntax
-
- An implementation supporting this document type shall support the
- transfer syntax generation rules named in Table 6.10 for all
- presentation data values transferred. Implementation may
- optionally support other named transfer syntaxes.
-
- 11. ASE specific specifications for FTAM
-
- 11.1 Simplification and relaxation
-
- 11.1.1 Structural simplification
-
- This simplification loses information.
-
- The document type NBS-7 may be accessed as a document type FTAM-3
- (allowed only when reading the file) by specifying document type
- FTAM-3 in the <contents type> parameter in <F-OPEN request>, and
- limiting access context to UA on F-READ.
-
- The octet representation of the transferred data is
- unpredictable. It will usually correspond to the data values as
- stored in the local Real Filestore of the Responder.
-
- A document of type NBS-7 can be accessed as a document of type
- NBS-6 (allowed only when reading the file) by specifying document
- type NBS-6 with appropriate data type parameters in the <contents
- type> parameter on the <F-OPEN request>.
-
- 11.2 Access context selection
-
- A document of type NBS-7 may be accessed in any one of the access
- contexts defined in the NBS-ordered-flat constraint set. The
- presentation data units transferred in each case are those
- derived from the structuring elements defined for that access
- context in ISO 8571-2.
-
- 11.3 The INSERT operation
-
- When the <INSERT> operation is applied at the end of file the
- transferred material shall be the series of FADUs which would be
- generated by reading any NBS-7 document with the same parameter
- values in access context FA.
- NBS-8 Indexed sequential file
- 1. Entry Number: NBS-8
- 2. Information objects
-
- Table 6.11 Information objects in NBS-8
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 document type name : {iso identified-organization icd (9999) 3
- 3 : organization-code (1) document 3
- 3 : type (5) indexed-file (8)} 3
- 3 : "NBS-8 FTAM indexed file" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 abstract syntax names: : {iso identified-organization icd (9999) 3
- 3 a) name for asname1 : organization-code (1) abstract- 3
- 3 : syntax (2) nbs-as1 (1)} 3
- 3 : "NBS abstract syntax AS1" 3
- 3 b) name for asname2 : {iso standard 8571 abstract-syntax(2) ftam- 3
- 3 : fadu (2)} 3
- 3 : "FTAM FADU" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)3
- 3 : } 3
- 3 : "Basic Encoding of a single ASN.1 type" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3parameter syntax: 3
- 3 PARAMETERS ::= SEQUENCE {DataTypes, KeyType, KeyPosition} 3
- 3 3
- 3 DataTypes ::= SEQUENCE OF CHOICE {Parameter0, Parameter1, Parameter2} 3
- 3 3
- 3 KeyType ::= CHOICE {Parameter0, Parameter1, Parameter2} 3
- 3 3
- 3 -- Parameter0, Parameter1, Parameter2, as defined for the 3
- 3 -- document types NBS-6, NBS-7 3
- 3 3
- 3 KeyPosition::= position INTEGER 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 file model : {iso standard 8571 file-model (3) 3
- 3 : hierarchical (1)} 3
- 3 : "FTAM hierarchical file model" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 constraint set : {iso standard 8571 constraint-set (4) 3
- 3 : ordered-flat (3) } 3
- 3 : "FTAM ordered flat constraint set" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 file contents: 3
- 3 Datatype1 ::= PrimType -- as defined in Annex 6 A, Part 3 3
- 3 Datatype2 ::= CHOICE { Node-Descriptor-Data-Element, 3
- 3 Enter-Subtree-Data-Element } 3
- 3 Exit-Subtree-Data-Element } 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- 3. Scope and field of application
-
- The document type defines the contents of a file for storage, for
- transfer and access using FTAM.
-
- Note: Storage refers to apparent storage within the Virtual Filestore.
-
- 4. References
-
- ISO 8571, Information Processing Systems - Open Systems
- Interconnection -File Transfer, Access and Management
-
- 5. Definitions
-
- This definition makes use of the terms data element, data unit and
- file access data unit as defined in ISO 8571-1.
-
- 6. Abbreviations
-
- FTAM File Transfer, Access and Management
-
- 7. Document semantics
-
- The document consists of zero, one or more file access data units,
- each of which consists of zero, one or more data elements. The order
- of each of these elements is significant.
-
- The document structure takes any of the forms allowed by the FTAM
- hierarchical file model as constrained by the FTAM ordered flat
- constraint set (see Table 6.11). These definitions appear in ISO
- 8571-2.
-
- The following additional requirements are specified for the use of the
- ordered flat constraint set:
-
- o The FADU identities 'first', 'last', and 'traversal number'
- are not required for conformant implementations
-
- o The identities 'next' and 'previous' are allowed for all
- FADUs
-
-
- Each data element is a data type from the set of primitive data types
- defined in Appendix 6A, Part 3 of this document. Each data unit
- contains the same data element types in the same order as all other
- data units. These types and their respective maximum lengths are
- defined by the <DataTypes> parameter.
-
- Note: The length values refer to the number of characters from the
- applicable type, not to the number of octets in the encoding, nor to
- the line length in any rendition of the document, where these are
- different.
-
- Each data unit in the file has a key associated with it. The key of
- each data unit is of the same data type as the key of all other data
- units in the file and is a single data element from the set of
- primitive data types defined in Appendix 6A, Part 3.
-
- The type and length of the key are defined by the <KeyType> parameter.
-
- The primitive data types and minimum size ranges of each unit which an
- implementation must accept as a key value are given in the following
- Table 6.12.
-
-
- Table 6.12 Datatypes for keys
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Key Type Minimum Range (octets) Order 3
- 3 3
- 3 ASN.1 INTEGER (1-2) increasing numeric value 3
- 3 ANS.1 IA5String (0-16) lexical order 3
- 3 ASN.1 GraphicString (0-16) lexical order 3
- 3 ANS.1 GeneralString (0-16) lexical order 3
- 3 ANS.1 OCTET STRING (0-16) increasing value 3
- 3 ASN.1 GeneralizedTime increasing time value 3
- 3 ASN.1 UniversalTime increasing time value 3
- 3 NBS-AS1 FloatingPointNumber increasing numeric value 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- The position of the key in the data unit is specified by the
- <position> parameter.
- position = 0 implies the key is not part of the data
- position > 0 specifies the actual data element in the data unit.
-
- 8. Abstract syntactic structure
-
- The abstract syntactic structure of the document is a hierarchically
- structured file as defined in the ASN.1 module ISO8571-FADU in ISO
- 8571, in which each of the file access data units has the abstract
- syntactic structure of NBS-AS1 as defined by the parameters.
-
- 9. Definition of transfer
-
- 9.1 Datatype definitions
-
- The file consists of data values which are of either
-
- a) Datatype1 defined in Table 6.11, where the PrimType in the
- datatype is given by the NBS-AS1 definition; or
-
- b) Datatype2 defined in Table 6.11, the ASN.1 datatype declared
- as "Data-Element" in the ASN.1 module ISO8571-FADU.
-
- 9.2 Presentation data values
-
- The document is transferred as a series of presentation data
- values, each of which is either
-
- a) one value of the ASN.1 datatype "Datatype1", carrying one of
- the data elements from the document. All values are
- transmitted in the same (but any) presentation context
- defined to support the abstract syntax name "asname1" or
-
- b) a value of "Datatype2". All values are transmitted in the
- same (but any) presentation context defined to support the
- abstract syntax name "asname2".
-
- Notes:
-
- 1. Specific carrier standards may impose additional constraints
- on the presentation context to be used, where the above
- permits a choice
- 2. Any document type defined in this entry either makes no use
- of Datatype2, or starts with a Datatype2 transmission.
-
- Boundaries between presentation data values in the same
- presentation context, and boundaries between P-DATA primitives,
- are chosen locally by the sending entity at the time of
- transmission, and carry no semantics of the document type.
- Receivers which support this document type shall accept a
- document with any of the permitted transfer options (e.g.
- document type parameters and transfer syntaxes).
-
- 9.3 Sequence of presentation data values
-
- The sequence of presentation data values of type a) and the
- sequence of presentation data values of types a) and b) is the
- same as the sequence of data elements within a Data Unit, and
- Data Units in the hierarchical structure, when flattened
- according to the definition of the hierarchical file model in ISO
- 8571-2.
-
- 10. Transfer syntax
-
- An implementation supporting this document type shall support the
- transfer syntax generation rules named in Table 6.11 for all
- presentation data values transferred. Implementation may
- optionally support other named transfer syntaxes.
-
- 11. ASE specific specifications for FTAM
-
- 11.1 Simplification and relaxation
-
- 11.1.1 Structural simplification
-
- This simplification loses information.
-
- The document type NBS-8 may be accessed as a document type FTAM-3
- (allowed only when reading the file) by specifying document type
- FTAM-3 in the <contents type> parameter in <F-OPEN request>, and
- limiting access context to UA on F-READ.
-
- The octet representation of the transferred data is
- unpredictable. It will usually correspond to the data values as
- stored in the local Real Filestore of the Responder.
-
- A document of type NBS-8 can be accessed as a document of type
- NBS-6 (allowed only when reading the file) by specifying document
- type NBS-6 with appropriate data type parameters in the <contents
- type> parameter on the <F-OPEN request>. The traversal order of
- the FADUs must be maintained.
-
- Note: The traversal order is as reading the file as NBS-8 in key
- order.
-
- 11.2 Access context selection
-
- A document of type NBS-8 may be accessed in any one of the access
- contexts defined in the FTAM ordered flat constraint set. The
- presentation data units transferred in each case are those
- derived from the structuring elements defined for that access
- context in ISO 8571-2.
-
- 11.3 The INSERT operation
-
- When the <INSERT> operation is applied the transferred material
- shall be the series of FADU which would be generated by reading
- any NBS-8 document with the same parameter values in access
- context FA.
-
- The insertion of a new FADU after an already existing FADU will
- be indicated via a diagnostic on TRANSFER-END.
-
- 11.4 The EXTEND operation
-
- This operation is excluded for the use with this document type.NBS-9 File directory file
-
- 1. Entry Number: NBS-9
-
- 2. Information objects
-
- Table 6.12 Information objects in NBS-9
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 document type name : {iso identified-organization icd (9999) 3
- 3 : organization-code (1) document 3
- 3 : type (5) file directory (9)} 3
- 3 : "NBS-9 FTAM file directory file" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 abstract syntax names: : {iso identified-organization icd (9999) 3
- 3 : organization-code (1) abstract 3
- 3 : syntax (2) nbs-as2 (2)} 3
- 3 : "NBS file directory entry abstract syntax" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)}3
- 3 : "Basic Encoding of a single ASN.1 type" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 parameter syntax 3
- 3 3
- 3 PARAMETERS ::= attribute-names [0] IMPLICIT BIT STRING { 3
- 3 3
- 3 -- Kernel group 3
- 3 3
- 3 read_filename (0), 3
- 3 read_permitted-actions (1), 3
- 3 read_contents-type (2), 3
- 3 3
- 3 -- Storage group 3
- 3 3
- 3 read_storage-account (3), 3
- 3 read_date-and-time-of-creation (4), 3
- 3 read_date-and-time-of-last-modification (5), 3
- 3 read_date-and-time-of-last-read-access (6), 3
- 3 read_date-and-time-of-last-attribute-modification(7),3
- 3 read_identity-of-creator (8), 3
- 3 read_identity-of-last-modifier (9), 3
- 3 read_identity-of-last-reader (10), 3
- 3 read_identity-of-last-attribute-modifier (11), 3
- 3 read_file-availability (12), 3
- 3 read_filesize (13), 3
- 3 read_future-filesize (14), 3
- 3 3
- 3 -- Security group 3
- 3 3
- 3 read_access-control (15), 3
- 3 read_legal-qualifications (16), 3
- 3 3
- 3 -- Private group 3
- 3 3
- 3 read_private-use (17) } 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 6.12 Information objects in NBS-9 continued.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 file model : {iso standard 8571 file-model (3) 3
- 3 : hierarchical (1)} FTAM hierarchical file 3
- 3 : "FTAM hierarchical file model" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 constraint-set : {iso standard 8571 constraint-set (4) 3
- 3 : unstructured (1)} FTAM unstructured 3
- 3 : "FTAM unstructured constraint set" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 File contents: 3
- 3 3
- 3 Datatype1 ::= FileDirectoryEntry 3
- 3 --As defined by NBS-AS2 in Appendix A, 3
- 3 --Part 3 of this document 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- 3. Scope and field of Application
-
- This document defines the contents of a file for transfer (not for
- storage) using FTAM.
-
- 4. References
-
- ISO 8571, Information Processing Systems - Open Systems
- Interconnection -File Transfer, Access and Management.
-
- 5. Definitions
-
- This definition makes use of the terms data element, data unit and
- file access data unit as defined in ISO 8571-1
-
- 6. Abbreviations
-
- FTAM File Transfer, Access and Management.
-
- 7. Document Semantics
-
- The document consists of one file access data unit, which consists
- only of zero, one or more data elements of type <FileDirectoryEntry>
- (defined in NBS-AS2).
-
- The document structure takes any of the forms allowed by the FTAM
- hierarchical file model as constrained by the unstructured constraint
- set. These definitions appear in ISO 8571-1.
-
- The parameter of the document type is used on <F-OPEN request> to
- specify the desired attributes of each of the files on the Filestore,
- when reading the document.
-
-
- 8. Abstract syntactic structure
-
- The abstract syntactic structure of the document is a series of file
- directory entries, each of which is defined by the
- <FileDirectoryEntry> definition in NBS-AS2.
-
- Additional constraints are defined for this document type: File
- access actions are restricted to Read. File-directory files may be
- Selected, Opened, Read, Closed, and Deselected. They may not be
- Created or Deleted. They may not be Written or Modified (except as a
- side effect of actions performed on individual files contained within
- a file directory).
-
- 9. Definition of transfer
-
- 9.1 Datatype definition
-
- The file consists of zero or more values of Datatype1 defined in
- Table 6.13.
-
- 9.2 Presentation data values
-
- The document is transferred as a series of presentation data
- values. Each presentation data value shall consist of one value
- of the ASN.1 data type "Datatype1", carrying one of the file
- directory entries from the document.
-
- All values are transmitted in the same (but any) presentation
- context established to support the abstract syntax name "asname1"
- declared in Table 6.13.
-
- 9.3 Sequence of presentation data values
-
- The sequence of presentation data values is the same as the
- sequence of file directory entries within the Data Unit in the
- file.
-
- 10. Transfer syntax
-
- An implementation supporting this document type shall support the
- transfer syntax generation rules named in Table 6.13 for all
- presentation data values transferred. Implementations shall
- optionally support other named transfer syntaxes.
-
- 11. ASE specific specifications for FTAM
-
- 11.1 Simplification and relaxation
-
- Relaxation is allowed to any bitstring combination of the
- document type parameter.
- Part 2: Constraint Sets
-
- NBS Ordered flat constraint set
-
- 1. Field of application
-
- The NBS-ordered flat constraint set applies to files which are
- structured into a sequence of individual FADUs and to which access may
- be made on an FADU basis by position in the sequence.
-
- 2. Basic constraints
- Table 6.14 Basic constraints for NBS Ordered flat
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Constraint set descriptor : "NBS ordered flat constraint set" 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Constraint set identifier : {iso identified-organization icd (9999)3
- 3 : organization-code (1) 3
- 3 : constraint-set (4) nbs-ordered-flat(1)}3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Node name : None 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 File access actions : Locate, Read, Insert, Erase, Replace 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Qualified action : None 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Available access contexts : HA, FA, UA 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Creation state : Root node without an associated data 3
- 3 : unit 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Location after open : Root node 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Beginning of file : Root node 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 End of file : No node selected; 'previous' gives last3
- 3 : node in traversal sequence,'current'and3
- 3 :'next'give an error. 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Read whole file : Read in access context FA or UA with 3
- 3 : FADU identity of 'begin'. 3
- FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
- 3 Write whole file (append) : Transfer the series of leaf FADUs which3
- 3 : would be generated by reading the whole3
- 3 : file in access context FA; perform the 3
- 3 : transfer with an FADU identity of 'end'3
- 3 : and a file access action of 'insert'. 3
- 3 : 3
- 3 Write whole file (replace) : Transfer the series of leaf FADUs which3
- 3 : would be generated by reading the whole3
- 3 : file in access-context HA; perform the 3
- 3 : transfer with FADU identity 'begin' and3
- 3 : file action of 'replace'. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDPDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- 3. Structural constraints
-
- The root node shall not have an associated data unit; all children of
- the root node shall be leaf nodes and may have an associated data
- unit; all arcs from the root node shall be of length one.
-
- 4. Action constraints
-
- Insert: The <Insert> action is allowed only at the end of file. If
- the FADU identity is 'end' the new node is inserted following all
- existing nodes in the file. If the FADU identity is 'traversal
- number', the number must be at least one greater than the traversal
- number of the last existing node. Any nodes between the last existing
- node and the new node are empty, i.e. nodes without data. If the FADU
- identity is a 'traversal number' not greater than that of the last
- existing node, an error will occur.
-
- Erase: The Erase action is only allowed at the root node to empty the
- file, with FADU identity of 'begin'. The result is a solitary root
- node without an associated data unit.
-
- Note: It is the intention when using this constraint set to allow for
- emptying an FADU, i.e. leaving an FADU with a DU of data length 0 (or
- without a DU); afterwards data may be reinserted into this hole. In
- order to empty an FADU, the <Replace> operation may be used with new
- data of length zero (or with an FADU whose <data exists> bit is set to
- 'false' and no DU). Refilling the hole is accomplished by a
- <Replace> operation with the new DU (or with the new FADU, whose <data
- exists> bit is set to 'true' and the new DU).
-
- 5. Identity constraints
-
- The FADU identity associated with the file action shall be one of the
- identities 'begin', 'end', 'first', 'last', 'current', 'next',
- 'previous' or a 'traversal number' greater than or equal to one. The
- actions with which these identities can be used are given in the
- following table.
-
- Table 6.15 Identity constraints in NBS Ordered flat
-
- ZDDDDDDDDBDDDDDDDBDDDDDBDDDDDBDDDDDDBDDDDDDDBDDDDDDBDDDDDDDDBDDDDDDDDDD?
- 3 Action 3 Begin 3 End 3First3 Last 3Current3 Next 3Previous3Traversal 3
- CDDDDDDDDEDDDDDDDEDDDDDEDDDDDEDDDDDDEDDDDDDDEDDDDDDEDDDDDDDDEDDDDDDDDDD4
- 3 3 3 3 3 3 3 3 3 3
- 3 Locate 3 valid 3valid3valid3 valid3 valid 3 valid3 valid 3 valid 3
- 3 3 3 3 3 3 3 3 3 3
- 3 Read 3 whole 3 3leaf 3 leaf 3 leaf 3 leaf 3 leaf 3 leaf 3
- 3 3 3 3 3 3 3 3 3 3
- 3 Insert 3 3valid3 3 3 3 3 3 leaf 3
- 3 3 3 3 3 3 3 3 3 3
- 3 Erase 3 whole 3 3 3 3 3 3 3 3
- 3 3 3 3 3 3 3 3 3 3
- 3 Replace3 whole 3 3leaf 3 leaf 3 leaf 3 leaf 3 leaf 3 leaf 3
- 3 3 3 3 3 3 3 3 3 3
- @DDDDDDDDADDDDDDDADDDDDADDDDDADDDDDDADDDDDDDADDDDDDADDDDDDDDADDDDDDDDDDY
- Part 3: Abstract Syntaxes
-
- Abstract Syntax NBS-AS1
-
- Abstract syntax name: {iso identified-organization icd (9999)
- organization-code (1) abstract-syntax (2) nbs-as1
- (1)}
- "NBS abstract syntax AS1"
-
- This is an abstract syntax for the set of presentation data values, each
- of which is a value of the ASN.1 type NBS-AS1.PrimType
-
- NBS-AS1 DEFINITIONS ::=
- BEGIN
- PrimType ::= CHOICE { INTEGER,
- BIT STRING,
- BOOLEAN,
- IA5String,
- GraphicString,
- GeneralString,
- OCTET STRING,
- UTCTime,
- GeneralizedTime,
- NULL,
- FloatingPointNumber }
-
- -- The support for IA5String is the IA5 G0
- -- character set and the IA5 C0 set
- -- The minimum level of support for
- -- GraphicString is the IA5 G0 character set and
- the 8859-1 G0 and G1 sets
- -- The minimum level of support for
- GeneralString is the IA5 G0 character set and
- the 8859-1 G0 and G1 character sets, and IA5
- C0 set.
-
- FloatingPointNumber ::= [PRIVATE 0] CHOICE {
- finite [0] IMPLICIT SEQUENCE
- { Sign,
- mantissa BIT STRING,
- -- first bit must be 1
- exponent INTEGER},
- infinity [1] IMPLICIT Sign,
- signalling-nan [2] IMPLICIT NaN,
- quiet-nan [3] IMPLICIT NaN,
- zero [4] IMPLICIT NULL }
-
- Sign ::= INTEGER { positive (0), negative (1) }
- NaN ::= INTEGER
- END
-
- For this abstract syntax the following transfer syntax can be used
- {joint-iso-ccitt asn1 (1) basic-encoding (1)}
- "Basic Encoding of a single ASN.1 type"
-
- Notes: 1. The mantissa is a number in the range (1/2 <mantissa<1).
- 2. The value is equal to mantissa * 2 exponent.
- 3. The first bit in the mantissa is most significant.
- 4. See IEEE 754 for definitions of terminology, such as NaN.
- 5. A minimum length range (in bits) is required for the
- components of <FloatingPointNumber>, as follows: mantissa 1-
- 23 bits, and exponent 0-8 bits.
-
-
-
- Abstract Syntax NBS-AS2
-
- Abstract syntax name: { iso identified-organization icd (9999)
- organization-code (1) abstract-syntax (2)
- nbs-as2 (2) }
-
- "NBS file directory entry abstract syntax"
-
- This is an abstract syntax for the set of presentation data values, each
- of which is a value of the ASN.1 Type NBS-AS2.FileDirectoryEntry.
-
- NBS-AS2 DEFINITIONS ::=
-
- BEGIN
-
- FileDirectoryEntry ::=[PRIVATE 2] Read-Attributes
-
- Read-Attributes ::=ISO8571-FTAM.Read-Attributes
-
- END
-
- For this abstract syntax the following transfer syntax will be used
-
- { joint-iso-ccitt asn1 (1) basic-encoding (1) }
-
- "Basic Encoding of a single ASN.1 type"
-
-
- Abstract Syntax "FTAM unstructured text abstract syntax"
-
- This abstract syntax is defined as DataType1 (File Contents) in Table 19
- of ISO 8571-2, Annex B.
-
-
- Abstract Syntax "FTAM unstructured binary abstract syntax"
-
- This abstract syntax is defined as DataType1 (File Contents) in Table 21
- of ISO 8571-2, Annex B.Part 4: Intentionally Left Empty
- 7. CCITT 1984 X.400 BASED MESSAGE HANDLING SYSTEM
-
- 7.1 INTRODUCTION
-
- This is an implementation agreement developed by the Implementor's
- Workshop sponsored by the U.S. National Bureau of Standards to promote
- the useful exchange of data between devices manufactured by different
- vendors. This agreement is based on, and employs protocols developed
- in accord with, the OSI Reference Model. While this agreement
- introduces no new protocols, it eliminates ambiguities in
- interpretations.
-
- This is an implementation agreement for a Message Handling System
- (MHS) based on the X.400-series of Recommendations (1984) and Version
- 5 of the X.400 Series Implementor's Guide from the CCITT. It is
- recommended that product vendors consult later versions of this guide.
- Figure 7.1 displays the layered structure of this agreement.
-
- This agreement can be used over any Transport protocol class. In
- particular, this MHS agreement can be used over the Transport protocol
- class 0 used over CCITT X.25, described in section 4.6 of this
- document. In addition, this MHS agreement can be used over the
- Transport profiles used in support of MAP (Manufacturing Automation
- Protocol) or TOP (Technical and Office Protocols). Note that the MAP
- or TOP environment must support the reduced Basic Activity Subset
- (BAS) as defined in X.410.
-
- The UAs and MTAs require access to directory and routing services. A
- Directory Service is to be provided for each (vendor-specific) domain.
- Except insofar as they must be capable of providing addressing and
- routing described hereunder, these services and associated protocols
- are not described by this agreement.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 User Agent Layer CCITT X.420 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 Message Transfer Agent Layer CCITT X.411 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 Reliable Transfer Service Layer CCITT X.410 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 Presentation Layer CCITT X.410 sec. 4.2 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 Session Layer See Section 5.1.1 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Figure 7.1 The layered structure of this implementation agreement
-
-
- 7.2 SCOPE
-
- This agreement applies to Private Management Domains (PRMDs) and
- Administration Management Domains (ADMDs). Four boundary interfaces
- are specified:
-
- (A) PRMD to PRMD;
- (B) PRMD to ADMD;
- (C) ADMD to ADMD.
- (D) MTA to MTA (within a PRMD, e.g., for MTAs from different
- vendors.)
-
- In case A, the PRMDs do not make use of MHS services provided by an
- ADMD. In cases B and C, UAs associated with an ADMD can be the source
- or destination for messages. Furthermore, in cases A and B, a PRMD
- can serve as a relay between MDs, and in cases B and C an ADMD can
- serve as a relay between MDs. Figure 7.2 illustrates the interfaces
- to which the agreement applies.
-
- X.400 protocols other than the Message Transfer Protocol (P1) and the
- Interpersonal Messaging Protocol (P2) are beyond the scope of this
- agreement. Issues arising from the use of other protocols or relating
- to P1 components in support of other protocols are outside the scope
- of this document. This agreement describes the minimum level of
- services provided at each interface shown in Figure 7.2. Provision
- for the use of the remaining services defined in the X.400 Series of
- Recommendations is outside the scope of this document.
-
- With the exception of intra domain connections, this agreement does
- not cover message exchange between communicating entities within a
- domain even if these entities communicate via P1 or P2. Bilateral
- agreements between domains may be implemented in addition to the
- requirements stated in this document. Conformance to this agreement
- requires the ability to exchange messages without use of bilateral
- agreements.
-
- PRMD = Private Management Domain
- ADMD = Administration Management Domain ZDDDDD?
- 3PRMD 3
- @DDBDDY
- ZDDDDDDDDDDDDDD? | ---3----A
- 3 PRMD 3 | ZDDADD?
- 3 ZDDDDDDD? CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4PRMD 3
- 3 3 MTA A 3 3 | @DDBDDY
- 3 @DDDBDDDY 3 | A ---3----B
- 3 ---3---D 3 | ZDDADD?
- 3 ZDDDADDD? CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4ADMD 3
- 3 3 MTA B 3 3 | @DDBDDY
- 3 @DDDDDDDY 3 | ---3----C
- @DDDDDDDDDDDDDDY B ZDDADD?
- 3ADMD 3
- @DDDDDY
-
-
- Figure 7.2 This agreement applies to the interface between: (A)
- PRMD and PRMD; (B) PRMD and ADMD; (C) ADMD and ADMD;
- and (D) MTA and MTA
-
-
- 7.3 STATUS
-
- This version of the X.400 based Message Handling System implementation
- agreements was completed on December 17, 1987. No further
- enhancements will be made to this version. See the next
- section--Errata.
-
-
- 7.4 ERRATA
-
-
- 7.5 PRMD to PRMD
-
- 7.5.1 Introduction
-
- This section is limited in scope to issues arising from the direct
- connection (interface A in Figure 7.2) of two PRMDs. "Direct" means
- that no ADMD or relaying PRMD provides MHS services to facilitate
- message interchange. "Direct" does not exclude those instances for
- which Administrations happen to be ADMDs but are not providing X.400
- services, that is, they are used only to provide lower layer services
- such as X.25. Figure 7.3 schematically represents the scope of this
- section.
-
- These issues relate to the use of the UAL (User Agent Layer) and MTL
- (Message Transfer Layer) services, protocol elements, recommended
- practices and constraints. In particular, this section addresses the
- P1 and P2 protocols and their related services in a direct connection
- environment. This section describes the minimum level of services
- provided by a PRMD. Provision for the use of the remaining services
- defined in the X.400 Series of Recommendations is beyond the scope of
- this section.
-
-
- ZDDDDDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDDDDDDDD?
- 3 Private Domain X 3 3 Private Domain Y 3
- 3 3 3 3
- 3 3 3 3
- 3 3 3 3
- 3 3 3 3
- 3 ZDDDDD? 3 3 ZDDDDDD? 3
- 3 ZD>3 UA 3<DDDDDDEDDDDDDDDDDDDD P2 DDDDDDDDDDDDDDDDEDDDD>3 UA 3<D? 3
- 3 3 CDDDDD4 3 3 CDDDDDD4 3 3
- 3 3 3 MTA 3<DDDDDDEDDDDDDDDDDDDD P1 DDDDDDDDDDDDDDDDEDDDD>3 MTA 3 3 3
- 3 3 @DDDDDY 3 3 @DDDDDDY 3 3
- 3 3 /3\ 3 3 /3\ 3 3
- 3 3 3 3 3 3 3
- 3 000000000000000 3 3 00000000000000 3
- 3 0the00000000000 3 3 0the0000000000 3
- 3 0remainder of00 3 3 0remainder of0 3
- 3 0Domain X000000 3 3 0Domain Y00000 3
- 3 0NETWORK0000000 3 3 0NETWORK000000 3
- 3 000000000000000 3 3 00000000000000 3
- @DDDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDDDDDDDY
-
-
- Figure 7.3 Interconnection of private domains
-
-
- 7.5.2 Service Elements and Optional User Facilities
-
- This section identifies those service elements and optional user
- facilities that must be provided in support of P1 and P2.
-
- 7.5.2.1 Classification of Support for Services
-
- The classification of UA and MT-Service elements is used to
- define characteristics of equipment. Equipment can claim
- SUPPORT or NON-SUPPORT of a Service; in the case of
- UA-service elements, a separate classification is given for
- Origination and Reception.
-
- The service provider is defined as the entity providing the
- service, in this case, the MTL or the UAL. The service user
- is either the MHS user or the UAL. The classification of
- provider and user relates to the sublayer for which the
- service element is defined.
-
- 7.5.2.1.1 Support (S)
-
- a) Support means:
-
- o The service provider makes the service
- element available to the service user.
-
- o The service user gives adequate support to
- the MHS to invoke the service element or
- makes information associated with the service
- element available.
-
- b) Support for Origination means that:
-
- o The service provider makes the service
- element available to the service user for
- invocation.
-
- o The service user gives adequate support to
- the end user of the MHS to invoke the service
- element.
-
- c) Support for Reception means that:
-
- o The service provider makes information
- associated with the service element available
- to the service user.
-
- Note: A UA- or MT-service element can carry
- information from originator to recipient only if:
-
- o the service element is available to the
- originator,
- o the service element is available to the
- recipient, and
- o all intermediate steps carry the information.
-
- 7.5.2.1.2 Non Support (N)
-
- This means that the service provider is not required to
- make the service element available to the service user.
- However, the service provider should not regard the
- occurrence of the corresponding protocol elements as an
- error and should be able to relay such elements.
- Implementations making a profile available should
- indicate deviations (additions or deletions) with
- respect to the requirement in the profile.
-
- 7.5.2.1.3 Not Used (N/U)
-
- This means that although the Recommendation allows this
- service element, this profile does not use it.
-
- 7.5.2.1.4 Not Applicable (N/A)
-
- This means that this service element does not apply in
- this particular case (for originator or recipient).
-
- 7.5.2.2 Summary of Supported Services
-
- a) Within a PRMD, a User Agent must support all P2 BASIC
- IPM Services (X.400) and all P2 ESSENTIAL IPM Optional
- user facilities (X.401) subject to the qualifiers
- listed in Appendix 7A.
-
- b) Within a PRMD, a MTA must support all BASIC MT Services
- (X.400) and all ESSENTIAL MT optional user facilities
- (X.401) subject to the qualifiers listed in Appendix
- 7A.
-
- c) No support is required of the additional optional user
- facilities of X.401.
-
- 7.5.2.3 MT Service Elements and Optional User Facilities
-
- Tables 7.1 through 7.3 show the message transfer (MT)
- service elements and optional user facilities.
-
-
- Table 7.1 Basic MT service elements
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Support (S) or 3
- 3 Service Elements Non-support (N) 3
- 3 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 Access Management N/U1 3
- 3 Content Type Indication S 3
- 3 Converted Indication S 3
- 3 Delivery Time Stamp Indication S 3
- 3 Message Identification S 3
- 3 Non-delivery Notification S 3
- 3 Original Encoded Information Types Indication S 3
- 3 Registered Encoded Information Types N/U1 3
- 3 Submission Time Stamp Indication S 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- DDDDDDDDDDDDDDDD
-
- 1 Not applicable to co-resident UA and MTA.
-
-
-
- Table 7.2 MT optional user facilities provided to the UA-selectable on a
- per-message basis
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 Support (S) or 3
- 3 MT Optional User Facilities Categorization Non-support (N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 Alternate Recipient Allowed E S 3
- 3 Conversion Prohibition E S 3
- 3 Deferred Delivery E N2 3
- 3 Deferred Delivery Cancellation E N2 3
- 3 Delivery Notification E S 3
- 3 Disclosure of Other Recipients E N3 3
- 3 Explicit Conversion A N 3
- 3 Grade of Delivery Selection E S 3
- 3 Multi-destination Delivery E S 3
- 3 Prevention of Non-delivery Notification A N 3
- 3 Probe E N4 3
- 3 Return of Contents A N 3
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- Table 7.3 MT optional user facilities provided to the UA agreed for
- any contractual period of time
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Support (S) or 3
- 3 MT Optional User Facilities Categorization Non-Support (N)3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3Alternate Recipient Assignment A N 3
- 3Hold for Delivery A N/U 3
- 3Implicit Conversion A N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- DDDDDDDDDDDDD
-
- E: Essential optional user facility.
- A: Additional optional user facility.
- 2 A local facility subject to qualifiers in Appendix 7A.
- 3 Support not required for an originating MT user; support must be
- provided for recipient MT users.
- 4 Subject to qualifiers in Appendix 7A.
-
-
-
- 7.5.2.4 IPM Service Elements and Optional User Facilities
-
- Tables 7.4 through 7.5 show the IPM service elements and
- optional user facilities.
-
-
- Table 7.4 Basic IPM service elements
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 Origination Reception 3
- 3 Service Elements by UAs by UAs 3
- 3 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3Access Management N/U5 N/U5 3
- 3Content Type Indication S S 3
- 3Converted Indication N/A S 3
- 3Delivery Time Stamp Indication N/A S 3
- 3Message Identification S S 3
- 3Non-delivery Notification S N/A 3
- 3Original Encoded Information S S 3
- 3 Types Indication 3
- 3Registered Encoded Information Types N/A N/A5 3
- 3Submission Time Stamp Indication S S 3
- 3IP-message Identification S S 3
- 3Typed Body S S 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- 5 Does not apply to co-resident UA and MTA.
-
-
- Table 7.5 IPM optional facilities agreed for a contractual period of
- time
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 Support (S) or 3
- 3 Service Elements Categorization Non-Support (N)3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3Alternate Recipient Assignment A N 3
- 3Hold for Delivery A N 3
- 3Implicit Conversion A N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- Table 7.6 IPM optional user facilities selectable on a per-message basis
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 Origination Reception3
- 3 IPM Optional User Facilities by UAs by UAs 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3Alternate Recipient Allowed A (N) A (N)3
- 3Authorizing Users Indication A (N) E (S)3
- 3Auto-forwarded Indication A (N) E (S)3
- 3Blind Copy Recipient Indication A (N) E (S)3
- 3Body Part Encryption Indication A (N) E (S)3
- 3Conversion Prohibition E (S) E (S)3
- 3Cross-referencing Indication A (N) E (S)3
- 3Deferred Delivery E (N)6 N/A 3
- 3Deferred Delivery Cancellation A (N/U)6 N/A 3
- 3Delivery Notification E (S) N/A 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3Disclosure of Other Recipients A (N) E (S)3
- 3Expiry Date Indication A (N) E (S)3
- 3Explicit Conversion A (N) N/A 3
- 3Forwarded IP-message Indication A (N) E (S)3
- 3Grade of Delivery Selection E (S) E (S)3
- 3Importance Indication A (N) E (S)3
- 3Multi-destination Delivery E (S) N/A 3
- 3Multi-part Body A (N) E (S)3
- 3Non-receipt Notification A (N) A (N)3
- 3Obsoleting Indication A (N) E (S)3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3Originator Indication E (S) E (S)3
- 3Prevention of Non-delivery Notification A (N) N/A 3
- 3Primary and Copy Recipients Indication E (S) E (S)3
- 3Probe A (N) N/A 3
- 3Receipt Notification A (N) A (N)3
- 3Reply Request Indication A (N) E (S)3
- 3Replying IP-message Indication E (S) E (S)3
- 3Return of Contents A (N) N/A 3
- 3Sensitivity Indication A (N) E (S)3
- 3Subject Indication E (S) E (S)3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- DDDDDDDDDDD
-
- 6 A local facility subject to qualifiers in Appendix 7A.
-
- 7.5.3 X.400 Protocol Definitions
-
- This section reflects the agreements of the NBS/OSI Workshop
- regarding P1 and P2 protocol elements.
-
- 7.5.3.1 Protocol Classification
-
- The protocol classifications are defined below in table
- 7.7:
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 1) UNSUPPORTED = X 3
- 3 These elements may be generated, but no specific processing should 3
- 3 be expected in a relaying or delivering domain. A relaying domain 3
- 3 must at least relay the semantics of the element. The absence of 3
- 3 these elements should not be assumed, in a relaying or delivering 3
- 3 domain, to convey any significance. 3
- 3 3
- 3 2) SUPPORTED = H 3
- 3 These elements may be generated. However, implementations are not 3
- 3 required to be able to generate these elements. Appropriate 3
- 3 actions shall be taken in a relaying or delivering domain. 3
- 3 3
- 3 3) GENERATABLE = G 3
- 3 Implementations must be able to generate and handle these protocol 3
- 3 elements, although they are not necessarily present in all 3
- 3 messages generated by implementations of this profile. 3
- 3 Appropriate actions shall be taken in a relaying or delivering 3
- 3 domain. 3
- 3 3
- 3 4) REQUIRED = R 3
- 3 Implementations of this profile must always generate this protocol 3
- 3 element. However, its absence cannot be regarded as a protocol 3
- 3 violation as other MHS implementations may not require this 3
- 3 protocol element. Appropriate actions shall be taken in a 3
- 3 relaying or delivering domain. 3
- 3 3
- 3 5) MANDATORY = M 3
- 3 This must occur in each message as per X.411 or X.420 as 3
- 3 appropriate; absence is a protocol violation. Appropriate actions 3
- 3 shall be taken in a relaying or delivering domain. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Table 7.7 Protocol Classifications
-
-
- 7.5.3.2 General Statements on Pragmatic Constraints
-
- a) Where a protocol element is defined as a choice of
- Numeric String and Printable String (i.e.,
- Administration Domain Name and Private Domain
- Identifier), then a numeric value encoded as a
- printable string is equivalent to the same value
- encoded as a numeric string. This does not apply to
- the Country Name protocol element.
-
- b) The maximum number of recipients in a single MPDU is
- 32K - 1 (that is, 32767). However, no individual
- limits on the number of occurrences (recipients) are
- placed on the following protocol elements: Authorizing
- Users, Primary Recipients, Copy Recipients, Blind Copy
- Recipients, Obsoletes and Cross References.
- Additionally, there is no limit on the number of Reply
- to Users. This is a local matter for the originating
- system.
-
- c) Use of strings. A Printable String is defined in terms
- of the number of characters, which is the same number
- of octets. For T.61 strings the number of octets is
- twice the number of characters specified.
-
- d) The ability to generate maximum size elements is not
- required, with the exception of the component fields in
- the Standard Attribute List, in which case it is
- required.
-
-
- 7.5.3.3 MPDU Size
-
- The following agreements govern the size of MPDUs:
-
- o All MTAEs must support at least one MPDU of at least
- two megabyte.
-
- o The size of the largest MPDU supported by a UAE is a
- local matter.
-
-
- 7.5.3.4 P1 Protocol Elements
-
- 7.5.3.4.1 P1 Envelope Protocol Elements
-
- Table 7.8 contains Protocol Elements and their
- classes.
-
- Table 7.8 P1 protocol elements
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3MPDU 3
- 3 UserMPDU G 3
- 3 DeliveryReportMPDU G 3
- 3 3
- 3 ProbeMPDU H 3
- 3 3
- 3UserMDPU 3
- 3 UMPDUEnvelope M 3
- 3 UMPDUContent M 3
- 3 3
- 3UMPDUEnvelope 3
- 3 MPDUIdentifier M 3
- 3 originator ORname M 3
- 3 originalEncodedInformationTypes G 3
- 3 If this field is absent, then the 3
- 3 Encoded Information Type is 3
- 3 "unspecified". 3
- 3 ContentType M 3
- 3 UAContentID H Maximum length = 16 characters. 3
- 3 Priority G 3
- 3 PerMessageFlag G Maximum length = 2 octets. 3
- 3 deferredDelivery X 3
- 3 PerDomainBilateralInfo X No limit on number of occurrences. 3
- 3 RecipientInfo M Maximum number = 32K - 1 occurr- 3
- 3 ences. More severe limitations are 3
- 3 by bilateral agreement. 3
- 3 TraceInformation M 3
- 3UMPDUContent M 3
- 3 3
- 3MPDUIdentifier 3
- 3 GlobalDomainIdentifier M 3
- 3 IA5String M Maximum length = 32 characters, 3
- 3 graphical subset only. Refer to 3
- 3 T.50 for clarification of graphical3
- 3PerMessageFlag subset. 3
- 3 discloseRecipients H 3
- 3 conversionProhibited G 3
- 3 alternateRecipientAllowed H 3
- 3 contentReturnRequest X 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.8 P1 protocol elements, Continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- 3 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3PerDomainBilateralInfo 3
- 3 CountryName M Maximum length = 3 characters. 3
- 3 AdministrationDomainName M Maximum length = 16 characters. 3
- 3 BilateralInfo M Maximum depth = 8; maximum 3
- 3 length = 1024 octets 3
- 3 (including encoding). 3
- 3 RecipientInfo 3
- 3 recipient M 3
- 3 ExtensionIdentifier M Maximum value = 32K - 1 (32767). 3
- 3 perRecipientFlag M Maximum length = 2 octets. 3
- 3 ExplicitConversion X 3
- 3 3
- 3perRecipientFlag 3
- 3 ResponsibilityFlag M 3
- 3 ReportRequest M 3
- 3 UserReportRequest M 3
- 3 3
- 3TraceInformation Reference should be made to 3
- 3 Version 5 of the X.400 Imple- 3
- 3 mentor's Guide for information 3
- 3 GlobalDomainIdentifier M related to Trace sequencing. 3
- 3 DomainSuppliedInfo M 3
- 3 3
- 3DomainSuppliedInfo 3
- 3 arrival M 3
- 3 deferred X 3
- 3 action M 3
- 3 0=relayed (value) G 3
- 3 1=rerouted (value) H Rerouting is not required. 3
- 3 converted H 3
- 3 previous H 3
- 3 3
- 3ORName See section 7.5.3.5 3
- 3 3
- 3EncodedInformationTypes 3
- 3 bit string M Delivery can only occur if match 3
- 3 is made with Registered Encoded 3
- 3 Information Types. Individual 3
- 3 vendors may impose limits. 3
- 3 Maximum length = 4 octets. 3
- 3 G3NonBasicParameters X 3
- 3 TeletexNonBasicParameters X 3
- 3 PresentationCapabilities X 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.8 P1 protocol elements, Continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3DeliveryReportMPDU 3
- 3 DeliveryReportEnvelope M 3
- 3 DeliveryReportContent M 3
- 3 3
- 3 3
- 3 3
- 3DeliveryReportEnvelope 3
- 3 report M 3
- 3 originator M 3
- 3 TraceInformation M 3
- 3 3
- 3DeliveryReportContent 3
- 3 original M 3
- 3 intermediate G See comment at end of table. 3
- 3 UAContentID G 3
- 3 ReportedRecipientInfo M Maximum number = 32K - 1 3
- 3 occurrences. 3
- 3 returned H Can only be issued if specifically 3
- 3 requested in the originating 3
- 3 message. 3
- 3 billingInformation X Maximum depth = 8; maximum 3
- 3 length = 1024 octets (including 3
- 3 encoding). 3
- 3 3
- 3 3
- 3ReportedRecipientInfo 3
- 3 recipient M 3
- 3 ExtensionsIdentifier M 3
- 3 PerRecipientFlag M 3
- 3 LastTraceInformation M 3
- 3 intendedRecipient H 3
- 3 SupplementaryInformation X Maximum length = 64 characters. 3
- 3 Value is pending verification by 3
- 3 the CCITT SG VIII or XI. 3
- 3 3
- 3 3
- 3 3
- 3 3
- 3LastTraceInformation 3
- 3 arrival M 3
- 3 converted G 3
- 3 Report M 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.
- Table 7.8 P1 protocol elements, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3Report 3
- 3 DeliveredInfo G Generated if delivery is reported. 3
- 3 NondeliveredInfo G Generated if failure to deliver 3
- 3 is reported. 3
- 3DeliveredInfo 3
- 3 delivery M 3
- 3 typeofUA R This element must be generated with3
- 3 a PRIVATE value by PRMDs. 3
- 3 3
- 3NonDeliveredInfo 3
- 3 ReasonCode M 3
- 3 DiagnosticCode H Whenever possible, use a meaningful3
- 3 diagnostic code. 3
- 3 3
- 3ProbeEnvelope 3
- 3 probe M 3
- 3 originator M 3
- 3 ContentType M 3
- 3 UAContentID H Maximum length = 16 characters. 3
- 3 original G If this field is absent, then the 3
- 3 Encoded Information Type is 3
- 3 "unspecified". 3
- 3 3
- 3 3
- 3 TraceInformation M 3
- 3 3
- 3 PerMessageFlag G 3
- 3 3
- 3 contentLength H 3
- 3 PerDomainBilateralInfo X 3
- 3 RecipientInfo M Maximum number = 32K - 1 3
- 3 occurrences. 3
- 3GlobalDomainIdentifier 3
- 3 CountryName M Maximum length = 3 characters. 3
- 3 AdministrationDomainName (4) M Maximum length = 16 characters or 3
- 3 digits. 3
- 3 3
- 3 PrivateDomainIdentifier R Maximum length = 16 characters or 3
- 3 digits. This element must be 3
- 3 generated by PRMDs. 3
- 3 3
- 3 End of Definitions 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
-
- Notes on Table 7.8
-
- Comment on intermediate TraceInformation in the
- DeliveryReportContent in table 7.8: Audit and confirmed reports
- should not be requested by other than the originating domain for
- two reasons. First, the return path of the report may be
- different from the path taken by the original message, and it may
- exclude the domain that added the request for audit and confirmed
- to the message. Second, if the return path is different from the
- path of the original message, the originating domain would
- receive intermediate trace information that it did not request.
-
- 7.5.3.5 ORName Protocol Elements
-
- Only form 1 variant 1 O/R names are supported.
-
- Table 7.9 contains ORName protocol elements.
-
- These agreements interpret 1984 X.400 Section 3.4 to mean
- that the attributes in the ORName in the MPDU must identify
- exactly one UA, and that all the values for the attributes
- specified in the ORName must be identical to the values of
- the corresponding attributes associated with the recipient
- UA. Underspecified names that are unique are deliverable.
-
- Overspecified ORNames, ORNames with mismatching fields, and
- ambiguous names are to be non-delivered or sent to the
- alternate recipient as appropriate.
-
- Table 7.9 ORName protocol elements
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- 3 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3ORName 3
- 3 StandardAttributeList M 3
- 3 DomainDefinedAttributeList X 3
- 3 3
- 3StandardAttributeList (1) 3
- 3 CountryName R As defined in X.411, Maximum 3
- 3 length = 3 characters. 3
- 3 AdministrationDomainName (4) R Maximum length = 16 characters 3
- 3 or digits. 3
- 3 X121Address X Maximum length = 15 digits. 3
- 3 TerminalID X Maximum length = 24 characters. 3
- 3 PrivateDomainName (2) G Maximum length = 16 characters. 3
- 3 OrganizationName (2) G Maximum length = 64 characters. 3
- 3 UniqueUAIdentifier X Maximum length = 32 digits. 3
- 3 PersonalName G Maximum length of values of sub- 3
- 3 elements = 64 characters. 3
- 3 Note: The possibility that this 3
- 3 value may be reduced to 40 3
- 3 characters is for further 3
- 3 study by the CCITT. 3
- 3 3
- 3 OrganizationalUnit (3) G Maximum length = 32 characters per 3
- 3 occurrence. A maximum of four 3
- 3 occurrences are allowed. 3
- 3 3
- 3DomainDefinedAttributeList (5) Maximum = 4 occurrences. 3
- 3 type M Maximum length = 8 characters. 3
- 3 value M Maximum length = 128 characters. 3
- 3 3
- 3PersonalName 3
- 3 surName M Maximum length = 40 characters. 3
- 3 givenName G Maximum length = 16 characters. 3
- 3 initials G Maximum length = 5 characters; 3
- 3 excluding surname initial and 3
- 3 punctuation and spaces. 3
- 3 generationQualifier G Maximum length = 3 characters. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.9 ORName Protocol Elements, Continued
-
-
- Notes:
-
- 1. The following apply for comparison of the Standard Attributes of
- an O/R Name:
-
- a. Lower case is interpreted as upper case (for IA5).
-
- b. Multiple spaces may be interpreted as a single space.
- Originating domains shall only transmit single
- significant spaces. If multiple spaces are transmitted,
- non-delivery may occur.
-
- 2. At least one of these must be supplied.
-
- 3. These should be sent in ascending sequence, from the least
- significant <Organizational Unit> (lowest in organization
- hierarchy) to the most significant. Only those specified should
- be sent. (That is, an unspecified <Organizational Unit> should
- not be sent along as a field of [null] content, nor zero length,
- etc.)
-
- 4. This attribute shall contain one space in all ORNames of messages
- originated in a PRMD that is not connected to an ADMD, and in
- ORNames of recipients reachable only through a PRMD; otherwise,
- this attribute shall contain an appropriate ADMD name.
-
- 5. Some existing systems which will be accessed via an X.400 service
- (whether directly connected using X.400 protocols or otherwise)
- may require the provision of addressing attributes which are not
- adequately supported by Standard Attributes as defined in these
- Agreements. In such cases, Domain Defined Attributes are an
- acceptable means of carrying additional addressing information.
- Failure to support the specification and relaying of DDAs may
- prevent successful interworking with such existing systems until
- such time as all systems are capable of relaying and delivery
- using only the Standard Attribute list. Specific recommendations
- on the use of DDAs for particular applications are in the
- Recommended Practices Section 7.12, Appendix B.
-
- 7.5.3.6 P2 Protocol Profile (Based on [X.420])
-
- Tables 7.10 and 7.11 classify the support for the P2
- protocol elements required by this profile. The tables
- give restrictions and comments in addition to X.420.
-
- Restriction on length is one of the types of restrictions.
- The reaction of implementations to a violation of this
- restriction is not defined by this Profile.
-
- 7.5.3.6.1 P2 Protocol - Heading
-
- Table 7.10 below specifies the support for protocol
- elements in P2 Headings.
-
- Table 7.10 P2 heading protocol elements
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3UAPDU 3
- 3 IM-UAPDU G 3
- 3 SR-UAPDU X 3
- 3 3
- 3IM-UAPDU 3
- 3 Heading M 3
- 3 Body M 3
- 3 3
- 3Heading 3
- 3 IPMessageId M 3
- 3 originator R 3
- 3 authorizingUsers H 3
- 3 primaryRecipients G At least one of primaryRecipients, 3
- 3 copyRecipients G copyRecipients, or 3
- 3 blindCopyRecipients must be 3
- 3 blindCopyRecipients H present. 3
- 3 inReplyTo G 3
- 3 obsoletes H 3
- 3 crossReferences H 3
- 3 subject G Maximum length = 128 T.61 3
- 3 characters (256 octets);the ability3
- 3 to generate the maximum size 3
- 3 subject is not required. 3
- 3 expiryDate H 3
- 3 replyBy H 3
- 3 replyToUsers H 3
- 3 importance H Appropriate action is for further 3
- 3 study. 3
- 3 sensitivity H Appropriate action is for further 3
- 3 study. 3
- 3 autoforwarded H 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.10 P2 heading protocol elements, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3IPmessageId 3
- 3 ORName H 3
- 3 PrintableString M Maximum length = 64 characters. 3
- 3ORDescriptor 3
- 3 ORName H Specify the ORName whenever it is 3
- 3 possible. See Appendix 7B. 3
- 3 freeformName H Maximum length = 64 characters, 3
- 3 graphical subset only (128 octets.)3
- 3 telephoneNumber H Maximum length = 32 characters. 3
- 3 This allows for punctuation. It 3
- 3 does not take into account possible3
- 3 future use by ISDN. 3
- 3 3
- 3Recipient 3
- 3 ORDescriptor M 3
- 3 reportRequest X 3
- 3 replyRequest H 3
- 3 3
- 3Body No limit on number of BodyParts. 3
- 3 BodyPart G No limit on length of any BodyPart 3
- 3 or the depth of ForwardedIPMessage 3
- 3 BodyParts nested. Classification is3
- 3 subject to pending CCITT resolution3
- 3 3
- 3 3
- 3SR-UAPDU 3
- 3 nonReceipt H 3
- 3 receipt H 3
- 3 reported M 3
- 3 actualRecipient R 3
- 3 intendedRecipient H 3
- 3 converted X 3
- 3NonReceiptInformation 3
- 3 reason M 3
- 3 nonReceiptQualifier H 3
- 3 comments H Maximum length = 256 characters. 3
- 3 returned H May only be issued if specifically 3
- 3 requested by originator. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.10 P2 heading protocol elements, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3ReceiptInformation 3
- 3 receipt M 3
- 3 typeOfReceipt H 3
- 3 SupplementaryInformation X Maximum length = 64 characters. 3
- 3 Note: This value is pending 3
- 3 verification by the CCITT SG 3
- 3 VIII or IX. 3
- 3 3
- 3 End of Definitions 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- 7.5.3.6.2 P2 Protocol - BodyParts
-
- a) All BodyParts with identifiers in the range 0 up
- to and including 16K -1 are legal and should be
- relayed. BodyPart identifiers corresponding to
- X.121 Country Codes should be interpreted as
- described in Note 2 of figure 7.4.
-
- o Implementations are required to generate and
- image IA5Text.
-
- o Implementations should specify the other
- BodyPart types supported.
-
- o If an implementation supports a particular
- BodyPart type for reception, it should also
- be able to support that BodyPart type for
- reception if it is part of a
- ForwardedIPMessage.
-
- o For the BodyPart types currently considered,
- support for the protocol elements is as
- indicated in table 7.11.
-
- b) Privately Defined BodyParts
-
- This section describes an interim means for
- identifying privately defined BodyParts. This
- section shall be replaced in a future version
- taking into account CCITT recommendations with
- equivalent functionality.
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 BodyPart :: = CHOICE { 3
- 3 [0]IMPLICIT IA5Text, 3
- 3 [1]IMPLICIT TLX, 3
- 3 . 3
- 3 . 3
- 3 . 3
- 3 [234]IMPLICIT UKBodyParts, 3
- 3 . 3
- 3 . 3
- 3 . 3
- 3 [310]IMPLICIT USABodyParts, 3
- 3 . 3
- 3 . 3
- 3 . } 3
- 3 Where UKBodyParts and USABodyParts are defined as: 3
- 3 3
- 3 SEQUENCE {BodyPartNumber, ANY} 3
- 3 3
- 3 BodyPartNumber ::= INTEGER 3
- 3 3
- 3 3
- 3 3
- 3 3
- 3 3
- 3 Note 1: In the EncodedInformationTypes of the P1 Envelope, the 3
- 3 undefined bit must be set when a message contains a 3
- 3 privately defined BodyPart. Each UA that expects such 3
- 3 BodyParts should include undefined in the set of 3
- 3 deliverable EncodedInformationTypes it registers with the 3
- 3 MTA. 3
- 3 3
- 3 Note 2: All BodyPartNumbers assigned must be interpreted relative 3
- 3 to the BodyPart in which they are used, which is that 3
- 3 tagged with the value [310] for those defined within the 3
- 3 United States. The NBS assigns unique message 3
- 3 BodyPartNumbers for privately defined formats within the 3
- 3 United States. 3
- 3 3
- 3 Note 3: Refer to section 7.12.6 for recommendations regarding the 3
- 3 implementaion of USABodyParts. 3
- 3 3
- 3 3
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Figure 7.4 X.409 Definition of Privately Defined BodyParts
- 7.5.3.6.3 P2 BodyPart Protocol Elements
-
- Table 7.11 P2 BodyParts
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Elements Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3BodyPart 3
- 3 IA5Text G 3
- 3 TLX X 3
- 3 Voice X 3
- 3 G3Fax X 3
- 3 TIFO X 3
- 3 TTX X 3
- 3 Videotex X 3
- 3 NationallyDefined X 3
- 3 Encrypted X 3
- 3 ForwardedIPMessage H 3
- 3 SFD X 3
- 3 TIF1 X 3
- 3 unidentified X 3
- 3 3
- 3IA5Text 3
- 3 repertoire H 3
- 3 IA5String M For rendition of IA5Text see 3
- 3 Appendix 7C. 3
- 3TLX For further study by CCITT. 3
- 3 3
- 3Voice 3
- 3 Set For further study by CCITT. 3
- 3 BitString M 3
- 3 3
- 3G3Fax 3
- 3 numberOfPages X 3
- 3 P1.G3NonBasicParameters X 3
- 3 SEQUENCE (OF BIT STRING) M 3
- 3 BIT STRING H See Note. 3
- 3 3
- 3P1.G3NonBasicParameters Support for individual elements is 3
- 3 for further study. 3
- 3 3
- 3TIFO 3
- 3 T.73Document M 3
- 3 T.73ProtocolElement H See Note. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.11 P2 BodyParts, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Elements Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3TTX 3
- 3 numberOfPages X 3
- 3 telexCompatible X 3
- 3 P1.TeletexNonBasicParams X 3
- 3 SEQUENCE M 3
- 3 T61String H See Note. 3
- 3 3
- 3P1.TeletexNonBasicParams 3
- 3 graphicCharacterSets X 3
- 3 controlCharacterSets X 3
- 3 pageFormats X 3
- 3 miscTerminalCapabilities X 3
- 3 privateUse X 3
- 3 3
- 3Videotex 3
- 3 SET For further study by CCITT. 3
- 3 VideotexString M 3
- 3 3
- 3NationallyDefined 3
- 3 ANY M 3
- 3 3
- 3Encrypted 3
- 3 SET For further study by CCITT. 3
- 3 BIT STRING M 3
- 3 3
- 3ForwardedIPMessage 3
- 3 delivery H 3
- 3 DeliveryInformation H 3
- 3 IM-UAPDU M 3
- 3 3
- 3DeliveryInformation 3
- 3 P1.ContentType M 3
- 3 originator M 3
- 3 original M 3
- 3 P1.Priority G 3
- 3 DeliveryFlags M 3
- 3 otherRecipients H 3
- 3 thisRecipient M 3
- 3 intendedRecipient H 3
- 3 converted X 3
- 3 submission M 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.11 P2 BodyParts, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Elements Class Restrictions and Comments 3
- 3 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3SFD 3
- 3 SFD.Document M 3
- 3 3
- 3TIF1 3
- 3 T73 Document M 3
- 3 T73.ProtocolElement H See note. 3
- 3 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 3
- 3 3
- 3Note: This element is not an addition to the definition of the BodyPart. 3
- 3 It is described here to show that the SEQUENCE may contain zero 3
- 3 elements. A Problem Report has been submitted to the CCITT to 3
- 3 clarify whether this is permissible. The NBS/OSI Workshop will 3
- 3 adopt the CCITT decision. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- 7.5.4 Reliable Transfer Server (RTS)
-
- 7.5.4.1 Implementation Strategy
-
- Based on X.410 clause 3 and X.411 clause 3.5.
-
- 7.5.4.2 RTS option selection
-
- a) The maximum number of simultaneous associations is not
- limited in this profile; if the capacity of a system is
- exceeded, it should not initiate or accept additional
- associations.
-
- b) Associations are established by the MTA which has
- messages to transfer.
-
- c) Associations are released when they are not needed.
- Associations may also be ended prematurely due to
- internal problems of the RTS.
-
- d) For both monologue and two way alternate associations,
- the initiator keeps the initial turn.
-
- e) When establishing an RTS association, the following
- rules apply to the use of parameters in addition to
- those in X.410 clause 3.2.1:
-
- Dialogue mode: Monologue must be supported for this
- profile; two-way alternate is used only
- if both partners agree.
-
- Initial turn: Kept by the initiator of the
- association.
-
- f) The 'priority-mechanism' and the 'transfer-time limit'
- are regarded as local matters.
-
- 7.5.4.3 RTS Protocol Options and Clarifications
-
- Realization of the RTS protocol is subject to the following
- rules in addition to those specified in X.410 clause 4:
-
- a) One RTS association corresponds to one or more
- consecutive session connections (not concurrent ones).
- The first is opened with ConnectionData of type OPEN,
- and subsequent ones are opened with type RECOVER.
-
- b) Recovery of a Session connection is only by RTS
- initiator.
-
- c) Checkpoint size:
-
- o Checkpointing and No Checkpointing should be
- supported. Whenever possible, checkpointing
- should be used.
-
- o The minimum checkpointSize is 1 (that is, 1024
- octets).
-
- d) Window size:
-
- o Minimal value of 1 (if checkpointing is
- supported).
-
- o WindowSize = 1 means: After an S-SYNCH-MINOR
- request is sent, wait until the confirmation is
- received before issuing an S-DATA, S-SYNCH-MINOR,
- or S-ACTIVITY-END request.
-
- e) APDUs should not be blocked into one activity.
-
- f) Only one SSDU shall be transferred:
-
- o Between two adjacent minor synch points.
-
- o Between minor synch points and adjacent
- S-ACTIVITY-START and S-ACTIVITY-END requests.
-
- o Between S-ACTIVITY-START and S-ACTIVITY-END
- without checkpoints.
-
- g) A monologue association is defined as follows:
-
- o The RTS user responsible for establishing the
- association is called the initiator.
-
- o The initiator keeps the initial turn.
-
- o APDUs are transferred in the direction of the
- initiator to the recipient only.
-
- o There shall be no token passing.
-
- o Only the initiator can effect an orderly release
- of the association.
-
- h) A two-way alternate association is as described in
- X.410.
-
- i) In the UserData parameter of the S-U-ABORT, the
- ReflectedParameter will not be used in the
- AbortInformation element.
-
- j) When the S-ACTIVITY-RESUME is used to resume an
- activity in the same session connection as the one in
- which it started, this must happen immediately after
- the activity has been interrupted (i.e., no intervening
- activity can occur). Otherwise, X.410 clause 4.3
- paragraph 1 may be violated.
-
- k) When S-ACTIVITY-RESUME is used to resume an activity
- started in another session connection, the following
- conditions must be met:
-
- o The current session connection is of type
- "recover".
-
- o The value of OldSessionConnectionIdentifier in
- S-ACTIVITY-RESUME must match the value of the
- SessionConnectionIdentifier parameter used in the
- S-CONNECT of the prior session connection. This
- value is also identical to the
- SessionConnectionIdentifier in the ConnectionData
- (in PConnect, in SS-UserData) for the current
- session connection.
-
- o This must occur as the first activity of the next
- session connection for the same RTS-association.
- It must be the first, otherwise X.410 clause 4.5.1
- point 1 is violated.
-
- Note: It is in the same RTS-ASSOCIATION because the use of
- S-ACTIVITY-RESUME only makes sense within the scope of one
- RTS association.
-
- l) If the transfer of an APDU is interrupted before the
- confirmation of the first checkpoint, the value of the
- SynchronizationPointSerialNumber in S-ACTIVITY-RESUME
- should be zero, and the S-ACTIVITY-RESUME must be
- immediately followed by an S-ACTIVITY-DISCARD.
-
- m) In S-TOKEN-PLEASE, the UserData parameter shall contain
- an integer conforming to X.409 which conveys the
- priority.
-
- n) The receiving RTS can use the value of the Reason
- parameter in the S-U-EXCEPTION-REPORT to suggest to the
- sending RTS that it should either interrupt or discard
- the current activity. S-U-Exception Reports are
- handled as stated in Version 5 of the Implementors
- Guide pages 12-13, paragraph E-33.
-
- o) In the case of S-P-ABORT, the current activity (if any)
- is regarded as interrupted, rather than discarded.
-
- p) Table 7.12 illustrates the legal negotiation
- possibilities allowed by X.410 clause 4.2.1 regarding
- checkpoint size and window size.
-
- q) These agreements include the provisions of version 6 of
- the Implementors Guide identical in all respects to
- version 5, except that the following points have been
- added to section 3.5:
-
- o for section 4.4.1 of X.410;
- "If the receiving RTS receives an S-ACTIVITY-DISCARD
- indication primitive and has already issued a TRANSFER
- indication primitive, it aborts the connection (S-U-ABORT
- request) with the "transfer completed" version code."
-
- o for section 4.6.2 of X.410
- "The "transfer completed (7)" abort reason is used to
- indicate to the sending RTS that the receiving RTS could not
- discard the activity because it has already completed the
- transfer (issued a TRANSFER indication primitive)."
- Transfer completed (7) is also added to the table of abort
- reasons in this section.
-
- Table 7.12 Checkpoint window size of IP
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 acceptor answer 3
- CDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDD4
- 3 CS = 0 3 CS = m 3 CS = n 3
- 3(or unspecified)3 WS = j 3 WS = j 3
- 3 WS unspecified 3(or unspecified)3(or unspecified)3
- ZDDDDDDDDDBDDDDDDDDDDDDDDDABDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
- 3 3 CS = O 3 3 3 3
- 3 3(or unspecified)3 legal 3 legal 3 legal 3
- 3 3 WS = i 3 3 3 3
- 3initiator3(or unspecified)3 3 3 3
- 3proposal 3 3 3 3 3
- 3 CDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
- 3 3 CS = k 3 3 3 3
- 3 3 WS = i 3 legal 3 legal 3 not allowed 3
- 3 3(or unspecified)3 3 3 3
- @DDDDDDDDDADDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDY
-
- Legend:
-
- o CS means CheckpointSize
- o WS means WindowSize
- o i, j, k, m, and n are integer values with the following
- relations:
-
-
- 0 s m s k < n (values assigned to CS)
- 0 < j s i (values assigned to WS)
-
-
- o For unspecified parameters, the default applies. In this
- case,the numeric relations apply, that is, the default values
- substitutefor the unspecified integer.
-
- 7.5.4.4 RTS Protocol Limitations
-
- The RTS Protocol Limitations for this profile are listed in
- table 7.13.
-
- Table 7.13 RTS protocol elements
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restriction 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3PConnect M 3
- 3 DataTransferSyntax M Value = 0. 3
- 3pUserData M 3
- 3 checkpointSize H 3
- 3 windowSize H 3
- 3 dialogueMode H 3
- 3 ConnectionData M 3
- 3 applicationProtocol G Value = 1. 3
- 3 H Value = 8883. 3
- 3 ConnectionData 3
- 3 open G 3
- 3 recover G 3
- 3 3
- 3 open 3
- 3 RTS user data G 3
- 3 3
- 3 recover 3
- 3 SessionConnectionIdentifier G 3
- 3 3
- 3RTS user data 3
- 3 mTAName G Maximum length 32 characters 3
- 3 graphic subset of IA5 only. 3
- 3 password G Maximum length 64 octets 3
- 3 graphic subset of IA5 only. 3
- 3 < null RTS User Data > G Generated if other validation 3
- 3 methods are used. 3
- 3 3
- 3SessionConnectionIdentifier 3
- 3 CallingSSUserReference M Maximum length 64 octets including 3
- 3 encoding = 62 octets of T.61. 3
- 3 CommonReference M 3
- 3 AdditionalReferenceInformation H Maximum length 4 octets including 3
- 3 encoding = 2 octets of T.61. 3
- 3 3
- 3PAccept G 3
- 3 DataTransferSyntax M Value = 0. 3
- 3 pUserData M 3
- 3 checkpointSize H 3
- 3 windowSize H 3
- 3 ConnectionData M 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7.13 RTS protocol elements, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restriction 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3PRefuse G 3
- 3 RefuseReason M 3
- 3 3
- 3SS User Data G See Note 3
- 3 (in S-TOKEN-PLEASE) 3
- 3 3
- 3AbortInformation G 3
- 3 (in S-U-ABORT) 3
- 3 AbortReason H 3
- 3 reflectedParameter X Restricted to 8 bits. 3
- 3 3
- 3 End of Definitions 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Note: Generated if supplied by the RTS-user. The RTS use may specify
- a priority in the TURN-PLEASE primitive, and if so, it is carried as
- the SS-User-Data in S-TOKEN-PLEASE.
-
-
- 7.5.5 Use of Session Services
-
- The session requirements and use of session are covered in
- section 5 of this document.
-
- 7.5.6 Data Transfer Syntax
-
- This section defines Presentation Transfer Syntax and notation
- rules applicable to these agreements. Implementations must
- conform EXACTLY as specified in X.409 with no further
- restrictions. Appendix 7C defines rendition of IA5 Text and T61
- characters.
-
- 7.6 PRMD to ADMD and ADMD to ADMD
-
- 7.6.1 Introduction
-
- This section defines the implementation agreements that apply to
- the interface between two management domains when at least one is
- an ADMD. A message arriving at an ADMD has either no recipient
- within that domain or one or more recipients within that domain.
- In the former case, the ADMD serves as a relay between two or
- more domains and the actions required of that ADMD are
- independent of the nature (PRMD or ADMD) of the domains. In the
- latter case, the ADMD is responsible for delivering messages to
- the proper recipient(s) within its jurisdiction, and may also be
- responsible for relaying the message.
-
- Given the two roles for an ADMD, this section describes two
- distinct sets of functional requirements for an ADMD. The first
- is the relaying requirement that is needed to provide PRMD and
- other ADMD interworking. The second is analogous to the PRMD's
- support to its customers through the integrated UAs. These are
- distinct functional differences. The services provided to the
- UAs of an ADMD are independent of the requirement that an ADMD
- provide a function for interworking with any type of Management
- Domain (MD). Figure 7.5 illustrates the two roles played by an
- ADMD.
-
- This section is presented in the form of deviations from the
- agreements applicable to PRMD-to-PRMD (section 7.5). Unless
- explicitly noted in the remainder of this section, all of the
- specifications for PRMD to PRMD apply to PRMD to ADMD and ADMD to
- ADMD.
-
-
- ZDDDDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDDDDDD?
- 3 PRMD or ADMD 3 3 ADMD 3
- 3 ZDDDDDDDDDD? <--3---------------P2-------------------3--> ZDDDDDDDDD? 3
- 3 3 IPM - UA 3 3 3 3IPM - UA 3 3
- 3 CDDDDDDDDDD4 <--3---------------P1-------------------3--> CDDDDDDDDD4 3
- 3 3 MTA 3 3 3 3 MTA 3 3
- 3 @DDDDDDDDDDY 3 3 @DDDDDDDDDY 3
- @DDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDDDDDY
- (a)
-
- ZDDDDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDDDDDD?
- 3 PRMD or ADMD 3 3 PRMD or ADMD 3
- 3 ZDDDDDDDDDD? 3 3 ZDDDDDDDDDD? 3
- 3 3 IPM - UA 3 <--3---------------P2-------------------3-> 3 IPM - UA 3 3
- 3 CDDDDDDDDDD4 3 3 CDDDDDDDDDD4 3
- 3 3 MTA 3 3 3 3 MTA 3 3
- 3 @DDDDDDDDDDY 3 3 @DDDDDDDDDDY 3
- @DDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDDDDDY
- | |
- | |
- | |
- P1 P1
- | |
- | ZDDDDDDDDDDDDDDDDDD? |
- | 3 ADMD 3 |
- ---------------->3 ZDDDD? 3<------------------
- 3 3 MTA3 3
- 3 @DDDDY 3
- @DDDDDDDDDDDDDDDDDDY
-
- (b)
-
-
- Figure 7.5 An ADMD may (b) or may not (a) serve as a relay
-
-
- 7.6.2 Additional ADMD Functionality
-
- The following defines the additional ADMD specific functionality
- required over and above that specified in the PRMD section.
-
- 7.6.2.1 Relay Responsibilities of an ADMD
-
- ADMDs will relay all content types (not just P2) unchanged
- in the absence of a request for conversion.
-
- 7.6.2.2 P1 Protocol Classification Changes
-
- Table 7.14 describes the changes to the PRMD P1 Protocol
- classifications required for a delivering Administration
- domain (with respect to the original message; this means the
- domain which originates the delivery reports).
-
- Table 7.14 P1 Protocol Classification Changes for a Delivering ADMD
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 Protocol Elements Class 3
- 3 3
- 3 3
- 3 DeliveredInfo 3
- 3 typeOfUA H 3
- 3 3
- 3 ReportedRecipientInfo 3
- 3 SupplementaryInformation H See Note 1. 3
- 3 3
- 3 GlobalDomainIdentifier 3
- 3 PrivateDomainIdentifier H 3
- 3 3
- 3 3
- 3 3
- 3 3
- 3 For relaying Administration domains, the classifications are all "X"3
- 3 3
- 3 For originating Administration domains, these are all 3
- 3 "NOT APPLICABLE". 3
- 3 3
- 3 3
- 3 Note 1: Domains providing access to TELEX/TELETEX recipients, whether 3
- 3 directly or indirectly as a result of bilateral agreements 3
- 3 between domains, must ensure that this information, when 3
- 3 present, is accessible by the recipient of the delivery report. 3
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- 7.6.2.3 O/R Names
-
- O/R Names shall consist of:
-
- o CountryName,
- o AdministrationDomainName.
-
- as well as one of the following:
-
- o PrivateDomainName,
- o PersonalName,
- o OrganizationName,
- o OrganizationalUnit,
- o UniqueUAIdentifier,
- o X121Address.
-
- and permits the optional inclusion of a
-
- o DomainDefinedAttributeList.
-
- Note: The destination PrivateDomainName or OrganizationName
- must be present if destined for a PRMD. The ADMD relaying
- the message to that destination PRMD requires this element.
-
- 7.6.2.4 P1 ADMD Name
-
- Management Domains (MDs) must specify in the ADMD name field
- of the O/R Name StandardAttributeList in P1, the name of the
- Administration domain:
-
- o to which the message is being sent (in recipient names)
-
- o from which the message originated (in the originator
- name).
-
- 7.6.3 Interworking with Integrated UAs
-
- If the message originates at a UA owned by an ADMD, or is
- delivered to such a UA, the O/R Name follows the same Form 1
- Variant 1 constraints as the base specifications; except that the
- ADMD name is the name of the ADMD that owns the UA and instead of
- supplying a PRMD Name, one (or more) of the following must be
- provided:
-
- o OrganizationName,
- o OrganizationalUnit,
- o PersonalName.
-
- and may optionally include a
-
- o DomainDefinedAttributeList.
-
- 7.6.4 Differences with Other Profiles
-
- 7.6.4.1 TTC Profile
-
- There are no outstanding issues regarding interworking
- between TTC-conformant systems and NBS-conformant systems
- with the exception of the number of recipients and the
- supported MPDU sizes. The ExtensionIdentifier field may
- contain a maximum value of 32K-1; however, according to the
- current TTC profile, if a message with more than 256
- recipients is received, some TTC-conformant domain may
- generate a nondelivery notification. This also applies to
- the ReportedRecipientInfo in a delivery report. Further, a
- TTC MTA is required to handle an MPDU size of at least 32KB.
- The NBS required MPDU size is 2MB as covered in section
- 7.5.3.3. Other differences are shown in Appendix E. TTC is
- currently based on Version 4 of the Implementor's Guide.
-
- 7.6.4.2 CEPT Profile
-
- See Appendix 7E.
-
- 7.6.5 Connection of PRMDs to Multiple ADMDs
-
- Given that Management Domain names (both PRMD and ADMD) shall be
- unique within the U.S., then when an ADMD is presented a message
- for transfer from a PRMD, it will accept O/R Names (both
- originator and recipient) which have an AdministrationDomainName
- field value different than the Administration's name. "Accept"
- implies the attempt to route/deliver the message shall be made,
- as appropriate, based upon the knowledge that MD names are
- unique.
-
- Whether this functionality is required by an Administration for
- conformance to this agreement is for further study.
-
- If a PRMD is connected to two or more ADMDs which are not
- effectively connected (either directly or via a third ADMD), full
- X.400 functionality shall not be available. Problems occur
- especially in the areas of:
-
- o Naming,
- o Routing,
- o Replying.
-
- It should be noted that a single PRMD that is connected to more
- than one ADMD can be represented by more than one combination of
- country-name, ADMD-name, and PRMD name. For example, it may
- occur that the PRMD-name for a particular PRMD may take different
- values, depending on the ADMD-name. Implementors should be aware
- of the consequences of these possibilities on routing.
-
-
- 7.6.6 Connection of an ADMD to a Routing PRMD
-
- It is possible for a collection of interconnected private domains
- to establish one domain as the "gateway" to an ADMD, and hence to
- the world.
-
- If an ADMD is connected to such a gateway PRMD, the individual
- private domains shall be registered with the Administration.
- Administrations need not support such connections.
-
- Note also that upon receipt by the ADMD of a message originating
- somewhere within the PRMD collection, that the TraceInformation
- may contain more than one element.
-
- The X.400 Recommendations specify that an ADMD should not attempt
- to relay a message destined for another ADMD through a PRMD, thus
- an ADMD should ensure that messages destined for another ADMD are
- not relayed through a PRMD. It should be noted, however, that a
- relaying PRMD will relay any such message it receives.
-
- 7.6.7 Management Domain Names
-
- o All Management Domain Names (both Private and
- Administration) shall be unique within the U.S.
-
- o A central naming authority shall be established to register
- domain names.
-
- 7.6.8 Envelope Validation Errors
-
- For validation errors, a non-delivery notice shall be generated
- (if possible) with reason code of 'unableToTransfer' and
- diagnostic code of 'invalidParameters' (unless specified
- otherwise).
-
- ADMDs will validate P1 Envelopes in the following areas:
-
- a) The X.409 syntax of all elements should be checked.
-
- b) The pragmatic constraint limits (lengths of fields and
- number of occurrences of fields) should be checked.
-
- c) Semantic validation of the following elements should be
- done:
-
- o originator O/R Name,
- o recipient O/R Name in the RecipientInfo,
- o Priority.
-
- d) Only recipient Names with the responsibility flag set should
- be validated. The validation of O/R names is defined in
- 7.8.3.3; the validation of priority is defined in 7.8.3.7.1.
-
- MPDU Identifier Validation
-
- o Validation of the GlobalDomainIdentifier component of
- the MPDU Identifier is performed upon reception of a
- message (i.e., as a result of a TRANSFER.Indication).
-
- o The country name should be known to the validating
- domain, and depending on the country name, validation
- of the ADMD name may also be possible.
-
- o Additional validation of the GlobalDomainIdentifier is
- performed against the corresponding first entry in the
- TraceInformation. If inconsistencies are found during
- the comparison, a non-delivery notice with the above
- defined reason and diagnostic codes is generated.
-
- o A request will be generated to the CCITT for a more
- meaningful diagnostic code (such as
- 'InconsistentMPDUIdentifier').
-
- 7.6.9 Quality of Service
-
- 7.6.9.1 Domain Availability
-
- 7.6.9.1.1 ADMD Availability
-
- The goal is to provide 24 hour per day availability.
- Note that there will be periods of time when an ADMD
- may be unavailable due to maintenance windows in its
- supporting network or in an MTA within the domain.
-
- 7.6.9.1.2 PRMD Availability
-
- Although the goal of PRMD availability is also 24 hours
- per day, business reasons are likely to dictate some
- different level of availability. ADMDs shall require a
- profile from the PRMD that indicates its schedule of
- regular availability to the ADMD.
-
- 7.6.9.2 Delivery Times
-
- In the absence of standardized quality of service
- parameters, the following are agreed to. When standardized
- parameters from CCITT Study Group I become available, they
- shall be adopted.
-
- a) In table 7.15 the following delivery time targets are
- established:
-
- Table 7.15 Delivery Time Targets
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Delivery Class 95% Delivered Before 3
- 3 3
- 3 Urgent 3/4 hour 3
- 3 Normal 4 hours 3
- 3 Non-Urgent 24 hours 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- b) The interval(s) between retries and the number of retry
- attempts that an ADMD uses in attempting delivery to a
- PRMD or integrated UA, will be locally determined
- domain parameters. However, the total elapsed times
- after which delivery attempts will be stopped are shown
- in table 7.16. This implies that, after these times, a
- Non-Delivery Notice will be generated.
-
- An Administration shall continue to attempt delivery until
- the forced nondelivery time, even if the recipient domain
- has scheduled an unavailability window.
-
- Table 7.16 Forced Nondelivery Times
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Delivery Class NonDelivery Forced After 3
- 3 3
- 3 Urgent 4 hours 3
- 3 Normal 24 hours 3
- 3 Non-Urgent 36 hours 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- Note:Both tables apply to the period between acceptance by
- the originating MTA in the originating Administration domain
- to the time of delivery in the destination Administration
- domain. Transit time within PRMDs is NOT included in the
- above times.
-
- 7.6.10 Billing Information
-
- a) All aspects relating to billing, charging, tariffs,
- settlement, and in particular to the use of the
- billingInformation field in the delivery report, is subject
- to bilateral agreement, and shall not be addressed in these
- implementation agreements.
-
- b) No ADMD shall require a PRMD to supply or process billing
- information.
-
- 7.6.11 Transparency
-
- a) No P1 extensions, other than the MOTIS extensions are to be
- allowed (Reference A/3211). Should an ADMD receive a
- message containing P1 extensions, it shall generate a
- non-delivery notice (if possible) with reason code of
- unableToTransfer and diagnostic code of invalidParameters.
-
- If MOTIS elements are present, a relaying MTA can optionally:
-
- o Relay the message. If the MTA does relay, it must not
- drop any of the protocol elements.
-
- o Non-Deliver the message.
-
- A receiving MTA can optionally:
-
- o Deliver the message
-
- o Non-Deliver the message.
-
- b) The CCITT has been requested to establish a more meaningful
- diagnostic code (such as protocolError) for this occurrence.
- Such a code has now been provided in the Implementors Guide.
-
- c) P2 extensions shall be relayed transparently by ADMDs.
-
- 7.6.12 RTS Password Management
-
- RTS password management shall be a local matter. This includes:
-
- o password length
- o frequency of changes
- o exchange of passwords with communicating partners
- o loading passwords ( i.e., the timing of password
- changes with respect to active associations).
-
- 7.6.13 For Further Study
-
- Issues requiring further study are:
-
- o Intra-Domain Routing
- o Multi-Vendor Domains
-
- 7.7 INTER and INTRA PRMD CONNECTIONS
-
- 7.7.1 Introduction
-
- This section is limited in scope to issues arising from the
- indirect connection of a PRMD to another PRMD or to an ADMD, and
- to the interconnection of MTAs to form inter-PRMD connections.
- Indirect means that the connection is made via a relaying PRMD.
- The X.400 Recommendations describe the way that a PRMD connects
- to a ADMD and the way that an ADMD connects to another ADMD. The
- Recommendations do not, however, describe the way that a PRMD
- connects indirectly to an ADMD or another PRMD, nor do they
- describe the way that MTAs are connected within a PRMD. These
- configurations (shown in Figures 7.6 and 7.7) are useful, for
- example, in connecting equipment from different vendors at a
- single customer site.
-
- The P1 protocol and its related services for both inter and intra
- PRMD connections are addressed in this section. In addition, a
- method for routing within a PRMD is given. It is recognized that
- uniform methods for Administration, maintenance, and quality of
- service should be developed for such configurations, and this
- work is for further study.
-
- This section describes the minimum that must be provided in order
- to implement a relaying PRMD and a MTA within a PRMD.
-
- This section is presented in the form of deviations from
- agreements applicable to PRMD to PRMD connection (section 7.5).
- That is, unless specifically noted in the remainder of this
- section, the agreements in section 7.5 apply to both relaying
- PRMDs and MTAs within a PRMD.
-
- It should be noted that the comments regarding ORNames in Section
- 7.6.5 also apply to this section.
-
- 7.7.2 The Relaying PRMD
-
- A PRMD that has the capability of relaying messages to another
- PRMD is called a relaying PRMD. A PRMD implementation need not
- claim to be a relaying PRMD. A PRMD implementation which does
- claim to be a relaying PRMD must follow the implementation
- agreements in this section.
-
- 7.7.2.1 Relay Responsibilities of a PRMD
-
- The responsibilities of a relaying PRMD are the same as
- those of an ADMD (as specified in sections 7.6.8 and
- 7.6.2.1). In addition, the PRMD will simply deliver
- messages routed to it from an ADMD, even if this results in
- routing a message from the ADMD to the PRMD to another ADMD.
-
- 7.7.2.2 Interaction with an ADMD
-
- In order for an ADMD to route a message to ADMD A via ADMD
- B, it must know that A is reachable through B. Similarly,
- in order for any MD to route a message to PRMD A via a
- relaying PRMD B, it must know that A is reachable through B
- (see Figure 7.8).
-
- ZDDDDDDDD?
- 3 ADMD 3
- @DDDBDDDDY
- ZDDDDDDDD? ZDDDADDDD? ZDDDDDDDD?
- 3 PRMD A CDDDDDDDDDDD4 PRMD B CDDDDDDDDDDDD4 PRMD C 3
- @DDDDDDDDY @DDDDDDDDY @DDDDDDDDY
-
- Relay
-
- Figure 7.6 Relaying PRMD
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 PRMD 3
- 3 ZDDDDDD? ZDDDDDD? 3
- 3 3MTA A 3 3 MTA D3 3
- 3 @DDBDDDY @DDBDDDY 3
- 3 3 3 3 ZDDDDDDD?
- 3 3 3 3 3 ADMD 3
- 3 ZDDADDD? ZDDADDD? 3 3 3
- 3 3MTA B CDDDDDDDDDDDDDDD4 MTA CCDDDEDDD4 or 3
- 3 @DDDDDDY @DDDDDDY 3 3 3
- 3 3 3 PRMD 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY @DDDDDDDY
-
- Figure 7.7 Intra PRMD connections
-
-
- Note 1: Section 7.6.6 specifies that ADMDs are not required to
- connect to a relaying PRMD, but they are not precluded from doing
- so.
-
- Note 2: TraceInformation may have more than one sequence on
- submission of a message by a relaying PRMD to an ADMD.
-
-
- ZDDDDDDD?
- 3 MD D 3
- @DDDBDDDY
- ZDDDDDADDDDDDDDD?
- 3 relay 3 ZDDDDDDDDDD? ZDDDDDDDD?
- 3 MD C with 3DDDDDDD4 relay CDDDDDDDD4 MD A 3
- 3 a message 3 3 MD B 3 @DDDDDDDDY
- 3 for A 3 @DDDDDDDDDDY
- @DDDDDDDDDDDDDDDY
-
- Figure 7.8 MD C must know of A to route the message
-
- 7.7.3 Intra PRMD Connections
-
- A PRMD is composed of MTAs which cooperate to perform the
- functions expected of a domain. An MTA implementation need not
- claim to follow the implementation agreements of this section.
-
- 7.7.3.1 Relay Responsibilities of an MTA
-
- The relaying responsibilities of an MTA are the same as
- those of an ADMD (as specified in sections 7.6.8 and
- 7.6.2.1) with one exception: loop suppression within the
- domain is done using the MOTIS InternalTraceInfo protocol
- element. The MTA must validate the InternalTraceInfo (see
- section 7.8.3.5 for details on validation). In addition,
- the PRMD will simply deliver messages routed to it from an
- ADMD, even if this results in routing a message from the
- ADMD to the PRMD to another ADMD (please see section 7.6.6).
-
- 7.7.3.2 Loop Suppression within a PRMD
-
- a) The only mechanism defined in the X.400 Recommendations
- for suppressing loops is TraceInformation, which is
- added on a per domain basis to detect and suppress
- loops among domains. Loops among MTAs within a domain
- need to be detected and suppressed. This implies that
- each MTA must add trace information that is meaningful
- within the domain. The MOTIS solution of adding
- InternalTraceInfo to the P1 Envelope of a message was
- adopted. The definition of InternalTraceInfo is given
- in figure 7.9. The InternalTraceInfo is added by each
- MTA within a PRMD to handle a message, and it is
- examined in the same way as TraceInformation to detect
- and suppress loops.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 InternalTraceInfo ::= [APPLICATION 30] 3
- 3 IMPLICIT SEQUENCE OF 3
- 3 SEQUENCE { 3
- 3 MTAName, 3
- 3 MTASuppliedInfo } 3
- 3 3
- 3 MTAName ::= PrintableString 3
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- Figure 7.9 Definition of InternalTraceInfo
-
- If the MTAName and password of X.411 are used for
- validation, then it is recommended that the MTAName
- used for validation also be used in the
- InternalTraceInfo. However, there is a complication:
- in X.411, MTAName is an IA5String, and the MTAname
- defined by MOTIS is a PrintableString. Efforts will be
- made to change the MOTIS definition from
- PrintableString to IA5String.
-
- b) Three actions are defined in MTASuppliedInfo: relayed,
- rerouted, and recipientReassignment as shown in figure
- 7.10. The recipientReassignment action is not
- supported in these agreements. The ability to generate
- it is not required, and if it is present on an incoming
- message, the action field will be ignored.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 MTASuppliedInfo ::= SET { 3
- 3 arrival [0] IMPLICIT Time, 3
- 3 deferred [1] IMPLICIT Time OPTIONAL, 3
- 3 action [2] IMPLICIT INTEGER 3
- 3 { relayed(0), rerouted(1), recipientReassignment(2) } 3
- 3 previous MTAName OPTIONAL } 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- Figure 7.10 Defined Actions in MTASuppliedInfo
-
- 7.7.3.3 Routing Within a PRMD
-
- a) Routing within a PRMD is complicated by the lack of a
- directory standard. In particular, it constrains
- intra-domain routing decisions to be based on some
- combination of the intra-domain attributes of the O/R
- Name, Organization Name Organizational Units, and
- Personal Name. In order to enhance interworking and to
- reduce the difficulty of configuring intra-domain
- connections, it is useful to restrict the ways in which
- these may be used in making routing decisions.
-
- b) However, it is recognized that vendors may wish to
- provide MTAs with varying degrees of routing capability
- within a PRMD as a temporary expedient until
- appropriate standards for automated construction of
- directories and routing tables are available. This
- section assigns class numbers to certain levels of
- routing capability and discusses the consequences of
- using MTAs which fall into each class. The
- classification scheme will allow some diversity in
- allocating O/R Name space and in configuring
- intra-domain routes.
-
- c) When other methods are recommended by standards bodies,
- the classification scheme described here will become
- obsolete. Large-scale, multi-vendor PRMDs may not be
- practical in the absence of standardized methods.
-
- 7.7.3.3.1 Class Designations
-
- When it is clear that a message is to be delivered
- within a domain, the Country Name, ADMD Name, and PRMD
- Name have already served their purpose in determining
- the next MTA in the route to the recipient. The
- remaining fields that might be used on making routing
- decisions within the PRMD are the Organization Name,
- Organizational Units, and Personal Name.
-
- MTAs are classified by their ability to discriminate
- between O/R names when making routing decisions within
- a PRMD. Conformant MTAs will be classified as shown in
- table 7.17.
-
- Table 7.17 Conformant MTA Classifications
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Class 1 Class 2 Class 3 3
- 3 3
- 3 Organization Name H H H 3
- 3 SEQUENCE OF Organizational Unit X H H 3
- 3 Personal Name X X H 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
- a) An 'H' means that the MTA must be able to base its
- intra-domain routing decisions on the given
- component of the O/R Name. In particular, both
- Class 2 and Class 3 MTAs must be able to
- discriminate on all the members in a supplied
- sequence of OrganizationalUnits. A Class 3 MTA
- must be able to discriminate on all of the
- elements in a PersonalName.
-
- An 'X' means that the MTA need not have the
- ability to discriminate on the given component.
-
- b) There is a hierarchy in support of components.
- The ability to discriminate on a given component
- does not imply the requirement to do so: e.g., a
- Class 3 MTA is not required to have tables for
- every PersonalName in the domain. Equally, an MTA
- which can discriminate on OrganizationalUnits to
- make routing decisions need not always use the
- full sequence in an O/R Name if a partial sequence
- provides enough information.
-
- c) The above classifications only apply to routing
- decisions in selecting a next hop within a domain.
- All MTAs are entitled to examine the full O/R Name
- when identifying their own directly served UAs.
-
- d) The routing table of a Class 1 MTA will be
- relatively small, because intra-domain routing
- decisions are based solely on OrganizationName.
- The routing table of a Class 2 MTA may be
- substantially larger and more complex because of
- its ability to discriminate on OrganizationalUnits
- as well as OrganizationName to make routing
- decisions. The routing table of a Class 3 MTA may
- be larger still, because its use of the components
- of PersonalName in addition to the other
- information.
-
- 7.7.3.3.2 Specification of MTA Classes
-
- If an MTA implementation claims to follow the
- implementation agreements, it must be either a Class 1,
- Class 2, or a Class 3 MTA. The class of an MTA
- implementation should be specified so that PRMD
- administrators can choose equipment properly.
-
- 7.7.3.3.3 Consequences of Using Certain Classes of MTAs
-
- Definition: An MTA which accepts submission requests
- and furnishes delivery indications to a
- UA is said to "directly serve" the UA.
-
- a) The presence in a domain of an MTA acting as a
- Class 1 or Class 2 MTA imposes administrative
- restrictions on the assignment of O/R Names to UAs
- and in the configuration of routes within that
- domain.
-
- o A Class 1 MTA may directly serve UAs from
- several OrganizationNames. However, if a
- Class 1 MTA directly serves a UA with a given
- OrganizationName, no other MTA in the domain
- may directly serve a user with the same
- OrganizationName. This means that if all
- MTAs in a domain are Class 1, then all UAs
- with a given OrganizationName must be
- assigned to the same MTA.
-
- o A Class 2 MTA may directly serve UAs from any
- combination of OrganizationName and sequence
- of OrganizationalUnits. However, if a Class
- 2 MTA directly serves a UA with a given
- combination, no other MTA in the domain may
- directly serve a user with the same
- combination. This means that if all MTAs in
- a domain are Class 2, then all UAs with a
- given OrganizationName and sequence of
- OrganizationalUnits must be assigned to the
- same MTA.
-
- o A domain consisting entirely of Class 3 MTAs
- is free of all the above restrictions.
-
- b) If Class 1 or Class 2 MTAs are used to perform
- relaying within a PRMD containing MTAs of other
- classes, care must be exercised in determining the
- topology of the domain to avoid leaving certain
- UAs inacessible from certain MTAs within the
- domain. The example below shows one of the
- configurations that should be avoided. The
- example is intended to stimulate careful
- examination of the relationship between network
- and organizational topologies.
-
-
- ZDDDDDDDDDDDDDDD? ZDDDDDDDDDD? ZDDDDDDDDDDDDDDD?
- 3 MTA A 3 3 MTA B 3 3 MTA C 3
- 3 serving CDD ... DD4 CDD ... DD4 serving 3
- 3Organization X 3 3 (Class 1)3 3Organization X 3
- @DDDDDDDDDDDDDDDY @DDDDDDDDDDY @DDDDDDDDDDDDDDDY
-
- Figure 7.11 Example of a confirguration to be avoided
-
-
- In Figure 7.11, B will route all messages for
- Organization X to either A or C because B is a Class 1
- MTA. The administrator who created this configuration
- probably wanted B to route some messages for
- Organization X to A, and some to C. However, B does
- not have the capability for this because it is only a
- Class 1 MTA. The configuration in Figure 7.11 can be
- corrected by replacing B with a Class 2 or Class 3 MTA.
-
- 7.7.3.4 Uniqueness of MPDUidentifiers Within a PRMD
-
- When generating an IA5String in an MPDUIdentifier, each MTA
- in a domain must ensure that the string is unique within the
- domain. This shall be done by providing an MTA designator
- with a length of 12 octets which is unique within the
- domain, to be concatenated to a per message string with
- maximum length of 20 octets.
-
- Two pieces of information, the MTA name and MTA designator,
- need to be registered within a PRMD to guarantee uniqueness.
- This registration facility need not be automated. If the
- MTA name is less than or equal to 12 characters, it is
- recommended that it also be used as the MTA designator.
-
- 7.7.4 Service Elements and Optional User Facilities
-
- A PRMD made up of MTAs which support varying sets of service
- elements in addition to those required in these agreements may
- appear to provide inconsistent service for these elements. For
- example, if one MTA supports deferred delivery and another MTA
- does not, then deferred delivery can be used by some, but not
- all, users in the PRMD. Similarly, if one MTA supports return of
- contents and another does not, then a user outside of the PRMD
- will receive returned contents for messages sent to one user, but
- not for messages sent to another user. Note that this same
- inconsistency occurs when sending to two PRMDs which support
- different additional optional elements.
-
- 7.7.5 X.400 Protocol Definitions
-
- This section describes additions and modifications to section
- 7.5.3 which are required for implementation of a relaying PRMD or
- an MTA within a PRMD.
-
- 7.7.5.1 Protocol Classification
-
- a) The classification scheme given in section 7.5.3.1
- applies to elements passing from one PRMD to another.
- For both relaying PRMDs, and MTAs in a PRMD, the same
- classification scheme will be used, but within a PRMD
- the classification applies to elements passing from one
- MTA to another.
-
- b) In addition to the classifications given in section
- 7.5.3.1, a classification of Prohibited has been used.
-
- PROHIBITED = P
-
- This element shall not be used. Presence of this
- element is a protocol violation.
-
- 7.7.5.2 P1 Protocol Elements
-
- Table 7.18 contains protocol elements and their classes. An
- * signifies that the classification of the protocol element
- has not changed from Table 7.8.
-
- Table 7.18 P1 Protocol Elements
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3UMPDUEnvelope 3
- 3 MPDUIdentifier M* This field needs to be unique 3
- 3 within a PRMD. See sections 3
- 3 7.7.3.4 for the method of 3
- 3 ensuring uniqueness. 3
- 3 3
- 3 originator M* It is recommended that all 3
- 3 components of the originator's 3
- 3 ORName be included to help ensure 3
- 3 that reports can be returned. 3
- 3 3
- 3 TraceInformation M* The first MTA in the domain to 3
- 3 receive the message adds the 3
- 3 TraceInformation. Subsequent 3
- 3 MTAs can update the 3
- 3 TraceInformation in the event of 3
- 3 conversion or deferred delivery. 3
- 3 When a message is generated, the 3
- 3 originating MTA adds the 3
- 3 TraceInformation. 3
- 3 3
- 3 InternalTraceInfo M/P This element is mandatory for 3
- 3 envelopes transferred between 3
- 3 MTAs within a PRMD, and 3
- 3 prohibited in messages 3
- 3 transferred outside the domain. 3
- 3 Elements are always added to the 3
- 3 end of the sequence. (See Note 1)3
- 3 3
- 3InternalTraceInfo M MTANames within a PRMD must be 3
- 3 MTAName unique. See section 7.7.3.4 for 3
- 3 the method of assuring uniqueness 3
- 3 Maximum length = 32 characters. 3
- 3 3
- 3 MTASuppliedInfo M 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
-
- Table 7.18 P1 Protocol Elements, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3 3
- 3MTASuppliedInfo 3
- 3 arrival M 3
- 3 deferred X This field must be generated by 3
- 3 MTAs which perform deferred 3
- 3 delivery. 3
- 3 3
- 3 action M See section 7.7.3.2 for 3
- 3 restrictions on values of this 3
- 3 field. 3
- 3 3
- 3 previous X This field must be generated by 3
- 3 MTAs which perform rerouting. 3
- 3 3
- 3DeliveryReportEnvelope 3
- 3 TraceInformation M* The first MTA in the domain to 3
- 3 receive the report adds the 3
- 3 TraceInformation. When a report 3
- 3 is generated, the originating MTA 3
- 3 adds the TraceInformation. 3
- 3 3
- 3 InternalTraceInfo M/P This field is mandatory for 3
- 3 envelopes transferred between 3
- 3 MTAs within a PRMD, and 3
- 3 prohibited in messages 3
- 3 transferred outside the domain. 3
- 3 (See Note 1) 3
- 3DeliveryReportContent 3
- 3 intermediate InternalTraceInfo P If it were possible to include 3
- 3 this field in the delivery report 3
- 3 content, an audit and confirmed 3
- 3 report could be provided to 3
- 3 detect problems within a PRMD. 3
- 3 Efforts are being made to add 3
- 3 this field to the MOTIS 3
- 3 definition. 3
- 3 3
- 3DeliveredInfo 3
- 3 typeOFUA R* It is the responsibility of the 3
- 3 MTA generating the report to 3
- 3 generate this element. 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
-
- Table 7.18 P1 Protocol Elements, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3Element Class Restrictions and Comments 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3
- 3ProbeEnvelope 3
- 3 TraceInformation M* The first MTA in the domain to 3
- 3 receive the probe adds the 3
- 3 TraceInformation. When a probe 3
- 3 is generated, the originating MTA 3
- 3 adds the TraceInformation. 3
- 3 3
- 3 InternalTraceInfo M/P This field is mandatory for 3
- 3 envelopes transferred between 3
- 3 MTAs within a PRMD, and 3
- 3 prohibited in messages 3
- 3 transferred outside the domain. 3
- 3 (See Note 1) 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Note 1: The M classification is only applicable if an
- implementation is claiming conformance according to section
- 7.10.2, point (g) 4th bullet.
-
- 7.7.5.3 Reliable Transfer Server (RTS)
-
- In the pUserData of PConnect, the value of
- applicationProtocol should be 1. This value was chosen
- because the agreements on intra-domain connections are not
- strictly P1, nor are they MOTIS. Philosophically, it would
- be good to choose a new application protocol identifier for
- these agreements, but this introduces too many practical
- problems. Since these agreements are closer to P1 than to
- MOTIS, the value of 1 will be used. This will not cause
- interworking problems between domains, because the only
- deviation from P1 is the InternalTraceInfo, which will not
- be present in messages transferred outside of a domain.
-
- 7.8 ERROR HANDLING
-
- This section describes appropriate actions to be taken upon receipt of
- protocol elements which are not supported in this profile, malformed
- MPDUs, unrecognized O/R Name forms, content errors, errors in
- reports, and unexpected values for protocol elements.
-
- 7.8.1 MPDU Encoding
-
- The MPDU should have a context-specific tag of 0, 1, or 2. If it
- does not have one of these tags, it is not possible to figure out
- who originated the message. Therefore, the way this error is
- reported is a local matter.
-
-
- 7.8.2 Contents
-
- Once delivery to the UA has occurred, it is not possible to
- report errors in P2 information to the originator. In addition,
- it seems unreasonable to insist that the MTA that delivers a
- message ensure that the P2 content of the message is acceptable.
- As a result, the handling of content errors is a local matter.
-
- 7.8.3 Envelope
-
- This section describes the handling of errors in message
- envelopes. Some of the error conditions described below may be
- detected in a recipient's O/R Name. This may limit the reporting
- MTA's ability to generate a nondelivery notification that
- accurately reflects the erroneous O/R Name in the
- ReportedRecipientInfo. This handling of this situation is a
- local matter.
-
- 7.8.3.1 Pragmatic Constraint Violations
-
- In all cases of pragmatic constraint violation, a
- nondelivery report should be generated with a ReasonCode of
- unableToTransfer, and a DiagnosticCode of
- pragmaticConstraintViolation.
-
- 7.8.3.2 Protocol Violations
-
- a) If all required protocol elements are not present, a
- nondelivery report with a ReasonCode of
- unableToTransfer and a DiagnosticCode of
- protocolViolation should be generated.
-
- b) If a protocol element is expected to be of one type,
- but is encoded as another, then a nondelivery report
- with a ReasonCode of unableToTransfer and a
- DiagnosticCode of invalidParameters should be
- generated.
-
- 7.8.3.3 O/R Names
-
- a) The domain that has responsibility for delivering a
- message should also have the responsibility to send the
- nondelivery notification if the message cannot be
- delivered. Therefore, each MTA should only validate
- the O/R Names of recipients with responsibility flags
- set to TRUE. In addition, a nondelivery notification
- can only be sent if the originator's O/R Name is valid.
-
- b) If any element in the O/R Name is unrecognized or if
- the CountryName, AdministrationDomainName, and one of
- PrivateDomainName and OrganizationName (and, for ADMDs,
- PersonalName and OrganizationalUnit) are not all
- present, then a nondelivery report should be generated
- with a ReasonCode of unableToTransfer, and a
- DiagnosticCode of unrecognizedORName. If the message
- can be delivered even though the ORName is invalid,
- delivery is a local matter. Note, however, that if the
- message is delivered, the invalid ORName might be
- propagated through the X.400 system (e.g., by
- forwarding).
-
- c) If the O/R Name has all of the appropriate protocol
- elements and the message still cannot be delivered to
- the recipient, the following DiagnosticCodes may appear
- in the nondelivery report: unrecognizedORName,
- ambiguousORName, and uaUnavailable.
-
- 7.8.3.4 TraceInformation
-
- a) Since non-relaying domains need not do loop
- suppression, domains with responsibility for delivering
- the message need not be concerned about the semantics
- of the TraceInformation, that is, arrival time and
- converted EncodedInformationTypes can be provided to
- the UA without inspection by the MTAs of the domain as
- long as the TraceInformation is properly encoded
- according to X.409.
-
- b) When a message is accepted for relay, the relaying
- domain must check that a TraceInformation SEQUENCE has
- been added by the domain that last handled the message.
- If the appropriate TraceInformation was not added, this
- should be treated as a protocolViolation (section
- 7.8.3.2).
-
- c) In addition, the relaying domain must check that the
- information was added in the sequence defined by the
- rules for adding TraceInformation in the CCITT X.400
- Implementor's Guide. If the sequence is invalid,then a
- nondelivery report should be generated with a
- ReasonCode of unableToTransfer and a diagnosticCode of
- invalidParameters.
-
- Note: It would be desirable for the CCITT to add a
- diagnostic code of invalidTraceInformation to allow a more
- meaningful description of this problem. A request for this
- new diagnostic code will be submitted.
-
- 7.8.3.5 InternalTraceInfo
-
- This section applies only to MTAs which follow the
- agreements of section 7.7.
-
- a) When a message is accepted for relay from another MTA
- in the domain, the relaying MTA must check that an
- InternalTraceInfo SEQUENCE has been added by the MTA
- that last handled the message. If the appropriate
- InternalTraceInfo was not added, this should be treated
- as a protocolViolation (section 7.8.3.2).
-
- b) In addition, the relaying MTA must check that the
- information was added in the sequence defined by the
- rules for adding TraceInformation in the CCITT X.400
- Implementor's Guide. If the sequence is invalid, then
- a nondelivery report should be generated with a
- ReasonCode of unableToTransfer and a diagnosticCode of
- invalidParameters.
-
- Note:It would be desirable for the CCITT to add a diagnostic
- code of invalidTraceInformation to allow for a more
- meaningful description of this problem. A request for this
- new diagnostic code will be submitted.
-
- 7.8.3.6 Unsupported X.400 Protocol Elements
-
- The protocol elements defined in X.400 but unsupported by
- this profile are: the deferredDelivery and
- PerDomainBilateralInfo parameters of the UMPDUEnvelope, the
- ExplicitConversion parameter of RecipientInfo, and the
- alternateRecipientAllowed and contentReturnRequest bits of
- the PerMessageFlag. Appropriate actions are described below
- for domains that do not support the protocol elements.
-
- 7.8.3.6.1 deferredDelivery
-
- The delivering domain shall do one of the following:
-
- o deliver at once,
- o hold for deferred delivery,
- o return a nondelivery notification with a
- ReasonCode of unableToTransfer and a
- DiagnosticCode of noBilateralAgreement.
-
- 7.8.3.6.2 PerDomainBilateralInfo
-
- If a delivering domain receives this element, the
- element can be ignored.
-
- 7.8.3.6.3 ExplicitConversion
-
- If ExplicitConversion is requested the message should
- be delivered if possible. That is, if the UA is
- registered to accept the EncodedInformationTypes of the
- message, then the message should be delivered even
- though the requested conversion could not be performed
- along the route. If delivery is not possible, then a
- nondelivery report should be generated with a
- ReasonCode of conversionNotPerformed with no
- DiagnosticCode.
-
- 7.8.3.6.4 alternateRecipientAllowed
-
- If a delivering domain receives this element the
- element can be ignored.
-
- 7.8.3.6.5 contentReturnRequest
-
- If a delivering domain receives this element, the
- element can be ignored.
-
- 7.8.3.7 Unexpected Values for INTEGER Protocol Elements
-
- There are three INTEGERs in the P1 Envelope. Appropriate
- actions are described below for domains receiving unexpected
- values for Priority, ExplicitConversion, and ContentType.
-
- 7.8.3.7.1 Priority
-
- Additional values for Priority have been suggested by
- at least one group of implementors as upward compatible
- changes to the X.400 Recommendations. Therefore, if a
- PRMD receives an unexpected value for Priority, and
- this value is greater than one byte in length, a
- nondelivery report should be generated with a
- ReasonCode of unableToTransfer and DiagnosticCode of
- invalidParameters. If the value is less than or equal
- to one byte, the PRMD can either generate a nondelivery
- report as previously specified or interpret the
- Priority as normal and deliver or relay the message.
-
- 7.8.3.7.2 ExplicitConversion
-
- When an unexpected value is received for
- ExplicitConversion, it should be handled as in section
- 7.8.3.6.3.
-
- 7.8.3.7.3 ContentType
-
- If the ContentType is not supported by the delivering
- MTA, then a nondelivery report should be generated with
- a ReasonCode of unableToTransfer, and a DiagnosticCode
- of contentTypeNotSupported.
-
- 7.8.3.8 Additional Elements
-
- In the absence of multilateral agreements to the contrary,
- receipt of privately tagged elements and protocol elements
- in addition to those defined in X.400 will result in a
- nondelivery report with a ReasonCode of unableToTransfer and
- a DiagnosticCode of invalidParameters.
-
- The exceptions to this are the MOTIS elements. The
- treatment of MPDU's containing these MOTIS extensions is
- described in Section 7.6.11.
-
- 7.8.4 Reports
-
- There is no mechanism for returning a delivery or status report
- due to errors in the report itself. Therefore the handling of
- errors in reports is a local matter.
-
- 7.9 MHS USE OF DIRECTORY SERVICES
-
- 7.9.1 Directory Service Elements
-
- a) Recommendation X.400 recognizes the need of MHS users for a
- number of directory service elements. Directory service
- elements are intended to assist users and their UAs in
- obtaining information to be used in submitting messages for
- delivery by the MTS. The MTS may also use directory service
- elements to obtain information to be used in routing
- messages. Some functional requirements of directories have
- been identified and are listed below.
-
- o Verify the existence of an O/R name.
-
- o Return the O/R address that corresponds to the O/R name
- presented.
-
- o Determine whether the O/R name presented denotes a user
- or a distribution list.
-
- o Return a list of the members of a distribution list.
-
- o When given a partial name, return a list of O/R name
- possibilities.
-
- o Allow users to scan directory entries.
-
- o Allow users to scan directory entries selectively.
-
- o Return the capabilities of the entity referred to by
- the O/R name.
-
- o Provide maintenance functions to keep the directory
- up-to-date.
-
- b) In addition to functionality, a number of operational
- aspects must be considered. These include
- user-friendliness, flexibility, availability, expandability,
- and reliability.
-
- c) Currently, these aspects of directory service elements and
- procedures are under study by both the CCITT and the ISO.
- Both organizations are committed to the development of a
- single Directory Service specification for use by MHS and
- all other OSI based applications.
-
- Given the incomplete nature of the ongoing activities within
- the CCITT and the ISO, no implementation details will be
- provided now for MHS use of Directory Services.
- Implementation agreements for MHS Use of Directory Services
- will be issued when current activities within the CCITT and
- the ISO are stable.
-
- 7.9.2 Use of Names and Addresses
-
- a) It is recognized that these agreements enable a wide variety
- of naming and addressing attributes (see section 7.5.3.5
- ORName Protocol Elements) wherein each PRMD may adopt
- particular routing schemes within its domain.
-
- b) With the exception of the intra-domain connection
- agreements:
-
- These agreements make no attempt to recommend a standard
- practice for electronic mail addressing.
-
- c) Inter-PRMD addressing may be secured according to practices
- outside the scope of these agreements, such as:
-
- o manual directories
- o on-line directories
- o ORName address specifications
- o ORName address translation.
-
- d) Further, each PRMD may adopt naming and addressing schemes
- wherein the user view may take a form entirely different
- from the attributes reflected in table 7.9. And, each PRMD
- may have one user view for the originator form and another
- for the recipient form, and perhaps other forms of user
- addressing. In some cases (e.g., receipt notification)
- these user forms must be preserved within the constraints of
- these implementation agreements. However, mapping between
- one PRMD user form to another PRMD user form, via the X.400
- ORName attributes of these agreements, is outside the scope
- of these agreements.
-
- 7.10 CONFORMANCE
-
- 7.10.1 Introduction
-
- In order to ensure that products conform to these implementation
- agreements, it is necessary to define the types and degrees of
- conformance testing that products must pass before they may be
- classified as conformant. This section defines the conformance
- requirements and provides guidelines for the interpretation of
- the results from this type of testing.
-
- This section is incomplete and will be enhanced in future
- versions of this Agreement. Later versions will reflect the
- problems of conformance testing and will outline specific
- practices and recommendations to aid the development of
- conformance tests and procedures.
-
- 7.10.2 Definition of Conformance
-
- For this section, the term conformance is defined by the
- following:
-
- a) The tests indicated for this section are intended to
- establish a high degree of confidence in a statement that
- the implementation under test (IUT) conforms (or does not
- conform) to the agreements of this section.
-
- b) Conformance to a service element means that the information
- associated with the service element is made accessible to
- the user (person or process) whenever this agreement says
- that this information should be available.
-
- Accessible means that information must be provided
- describing how a user (person or process):
-
- o causes appropriate information to be displayed, or
- o causes appropriate information to be obtained.
-
- c) Conformance to P1, P2, and RTS as part of an X.400 OSI
- application requires that only the external behavior of that
- OSI system adheres to the relevant protocol standards.
-
- In order to achieve conformance to this section, it is not
- required that the inter-layer interfaces be available for
- testing purposes.
-
- d) Conformance to the protocols requires:
-
- o that MPDUs correspond to instances of syntactically
- correct data units,
-
- o MPDUs in which the data present in the fields and the
- presence (or absence) of those fields is valid in type
- and semantics as defined in X.400, as qualified by this
- profile,
-
- o correct sequences of protocol data units in responses
- (resulting from protocol procedures).
-
- e) Statements regarding the conformance of any one
- implementation to this profile are not complete unless a
- Protocol Implementation Conformance Statement (PICS) is
- supplied.
-
- f) The term "Implementation Under Test" (IUT) is
- interchangeable with the term "system" in the definition of
- conformance, and may refer to:
-
- o a domain, which may be one or more MTA's with
- co-located or remote UA's,
-
- o a single instance of an MTA and co-located UA with
- X.400 (P1, P2, RTS and session) software,
-
- o a relaying product with P1, RTS and session software,
-
- o a gateway product.
-
- g) Claiming Implementation Conformance
-
- o An implementation which claims to be conformant as an
- ADMD must adhere to the agreements in sections 7.5 and
- 7.6.
-
- o An implementation which claims to be conformant as a
- PRMD must adhere to the agreements in section 7.5.
-
- o An implementation which claims to be conformant as a
- relaying PRMD must adhere to the agreements in section
- 7.5 and the appropriate sections of 7.7.
-
- o An implementation which claims to be conformant to the
- intra-domain connection agreements must adhere to the
- agreements in section 7.5 and the appropriate sections
- of 7.7.
-
- 7.10.3 Conformance Requirements
-
- 7.10.3.1 Introduction
-
- Conformance to this specification requires that all the
- services listed as supported in sections 7.5, 7.6, and if
- appropriate, 7.7 of these agreements are supported in the
- manner defined, in either the CCITT X.400 Recommendations or
- these agreements. It is not necessary to implement the
- recommended practices of section 7.12, Appendix B, in order
- to conform to these agreements.
-
- It is the intention to adopt, where and when appropriate the
- testing methodology and/or the abstract test scenarios
- currently being defined by the CCITT X.400 Conformance
- Group. However, it is recognized that formal CCITT
- Recommendations relating to X.400 Conformance Testing will
- not be available until 1988. It is also recognized that
- aspects of these agreements are outside the scope of the
- CCITT, and that other organizations will have to provide
- conformance tests in these cases.
-
- 7.10.3.2 Initial Conformance
-
- This section is intended to provide guidelines to vendors
- who envisage having X.400 products available prior to any
- formal mechanism, or "Conformance Test Center" being made
- accessible that would allow for conformance to this product
- specification to be tested.
-
- It is feasible that vendors and carriers will want to enter
- bilateral test agreements that will allow for initial trials
- to be carried out for the purposes of testing initial
- interworking capabilities. It is equally feasible that for
- the purposes of testing interoperability, only a subset of
- this specification will initially be tested.
-
- Note: By claiming conformance to this subset of information
- the vendor or carrier CANNOT claim conformance to this
- entire specification.
-
- There are two aspects to the requirements, interworking and
- service, as described in the following sections.
-
- 7.10.3.2.1 Interworking
-
- The interworking requirements for conformance implies
- that tests be done to check for the syntax and
- semantics of protocol data elements for a system as
- defined by the classification scheme of sections
- 7.5.2.1.1 and 7.7.5.2. For a relay system, the correct
- protocol elements should be relayed as appropriate.
- For a recipient system, a message with correct protocol
- elements must not be rejected where appropriate.
-
- 7.10.3.2.2 Service
-
- For information available to the recipients via the
- IPMessage Heading and Body, the following should be
- made accessible:
-
- o IPMessage ID - only the PrintableString portion of
- the IPMessageId needs to be accessible.
- o subject,
- o primaryRecipients,
- o copyRecipients,
- o blindcopyRecipients,
- o authorizingUsers,
- o originator,
- o inReplyTo,
- o replyToUsers,
- o importance,
- o sensitivity,
- o IA5Text Bodypart.
- 7.11 APPENDIX A: INTERPRETATION OF X.400 SERVICE ELEMENTS
-
- The work on service element definitions is limited to those that are
- defined as 'supported' in section 7.5 of this specification. Furthermore
- it is not the intent of this section to define how information should be
- made available or presented to a MHS user, nor is it intended to define
- how individual vendors should design their products. In addition,
- statements on conformance to a specific service element and the
- allocation of error codes that are generated as a result of violations of
- the service should be defined in the sections on conformance and errors
- as part of the main product specification. The main objective is to
- provide clarification, where required, on the functions of a service
- element, and in particular what the original intent of the
- Recommendations were.
-
- SERVICE ELEMENTS
-
- The following Service Elements defined in X.400 have been examined and
- require further text to be added to their definitions to represent the
- proposed implementation of these service elements by the X.400 SIG.
-
- The service element clarifications are to be taken in the context of this
- profile.
-
- Service elements not referenced in this section are as defined in X.400.
-
- PROBE
-
- A PRMD need not generate probes.
-
- If a probe is addressed to and received by a PRMD, the PRMD must respond
- with a Delivery Report as appropriate at the time the probe was
- processed.
-
- DEFERRED DELIVERY
-
- In the absence of bilateral agreements to the contrary, Deferred Delivery
- and Deferred Delivery Cancellation are local matters (i.e., confined to
- the originating domain) and need not be provided.
-
- The extension of Deferred Delivery beyond the boundaries of the
- initiating domain is via bilateral agreement as specified in Section
- 3.4.2.1 of X.411.
-
- Content Type Indication
-
- It is required that both an originating and recipient domain be able to
- support P2 content type. The ability for domains to be able to exchange
- content types other than P2 will depend on the existence of bilateral or
- multi-lateral agreements.
-
-
- Original Encoded Information Types Indication
-
- It is required that both an originating and recipient domain be able to
- support IA5 text. Support for other encoded information types, for the
- purposes of message transfer between domains, will depend on the
- existence of bilateral or multi-lateral agreements.
-
- The use of the 'unspecified' form of encoded information type should only
- be used when the UMPDU content represents an SR-UAPDU or contains an
- auto-forwarded IM-UAPDU.
-
- The original encoded information type of a message is not meaningful
- unless a message is converted en route to the recipient. These
- agreements support only IA5 text, which should not undergo conversion.
- The original encoded information types should be made accessible to the
- recipient for upward compatibility with the use of non-IA5 text message
- body parts.
-
- Registered Encoded Information Types
-
- A UMPDU with an 'unspecified' value for Original Encoded Information Type
- shall be delivered to the UA.
-
- Delivery Notification
-
- The UAContentID may be used by the recipient of the delivery notification
- for correlation purposes.
-
- Disclosure of Other Recipients
-
- This service is not made available by originating MTAE's to UAE's, but
- must be supported by relaying and recipient MTAE's.
-
- By supporting the disclosure of other recipients the message recipient
- can be informed of the O/R names of the other recipient(s) of the
- message, as defined in the P1 envelope, in addition to the O/R
- Descriptors within the P2 header.
-
- These agreements do not support initiation of disclosure of other
- recipients, but the information associated with it should be made
- accessible to the recipient for upward compatibility with support for the
- initiation of this service element.
-
- Typed Body
-
- As defined in X.400 with the addition of the Private Body Types that are
- to be supported. At present there is no mechanism provided within X.420
- that would allow you to respond to reception of an unsupported body type.
-
- Action taken in this situation is a local matter.
-
-
- Blind Copy Recipient Indication
-
- It should be considered that the recipient's UA acts on behalf of the
- recipient, and therefore may choose to disclose all BCC recipients to
- each other. Therefore it is the responsibility of the originating domain
- to submit two or more messages, depending on whether or not each BCC
- should be disclosed to each other BCC.
-
- Auto Forwarded Indication
-
- A UA may choose not to forward a message that was previously
- auto-forwarded. In addition there is no requirement for an IPM UA that
- does not support non-receipt or receipt notification to respond with a
- non-receipt notification when a message is auto-forwarded.
-
- Primary and Copy Recipients Indication
-
- It is required that at least one primary recipient be specified; however,
- for a forwarded message this need not be present. The recipient UA
- should be prepared to accept no primary and copy recipients to enable
- future interworking with Teletex, Fax, etc.
-
- Sensitivity Indication
-
- A message originator should make no assumptions as to the semantic
- interpretation by the recipients UA regarding classifications of
- sensitivity. For example, a personal message may be printed on a shared
- printer.
-
- Reply Request Indication
-
- In requesting this service an originator may additionally supply a date
- by which the reply should be sent and a list of the intended recipients
- of the reply. If no such list is provided then the initiator of the reply
- sends the reply to the originator of the message and any recipients the
- reply initiator wishes to include. The replytoUsers and the replyBy date
- may be specified without any explicit reply being requested. This may be
- interpreted by the recipient as an implicit reply request. Note that for
- an auto-forwarded message an explicit or implicit reply request may not
- be meaningful.
-
- Body Part Encryption
-
- The original encoded information type indication includes the encoded
- information type(s) of message body parts prior to encryption by the
- originating domain. The ability for the recipient domain to decode an
- encrypted body part is a local matter. Successful use of this facility
- can only be guaranteed if there exists bilateral agreements to support
- the exchange of encrypted body parts.
-
-
- Forwarded IP message Indication
-
- The following use of the original encoded information type in the context
- of forwarded messages is clarified:
-
- o If forwarding a private message body part the originator of the
- forwarded message shall set the original encoded information
- types in the P1 envelope to undefined for that body part.
-
- o The encoded information types of the message being forwarded
- should be reflected in the new original encoded information types
- being generated.
-
- o See Appendix 7B on recommended practices for the use of the
- delivery information as part of Forwarded IP-message.
-
- Multipart Body
-
- It is the intent of multipart bodies to allow for the useful and
- meaningful structuring of a message that is constructed using differing
- body part types. For example, it is not recommended that a message made
- up of only IA5 text should be represented as a number of IA5 body parts,
- each one representing a paragraph of text.
- 7.12 APPENDIX B: RECOMMENDED X.400 PRACTICES
-
- It is not necessary to follow the recommended practices when claiming
- conformance to these agreements.
-
- 7.12.1 RECOMMENDED PRACTICES IN P2
-
- 1. ORDescriptor
-
- Vendors following the NBS/OSI Workshop guidelines shall,
- whenever possible, generate the ORName portion of an
- ORDescriptor in ALL IPM heading fields.
-
- 2. ForwardedIPMessage BodyParts
-
- ForwardedIPMessage BodyParts should be nested no deeper than
- eight. There is no restriction on the number of
- ForwardedIPMessage BodyParts at any given depth.
-
- 3. DeliveryInformation
-
- It is strongly recommended that DeliveryInformation be
- supplied in both forwarded and autoforwarded message body
- parts. DeliveryInformation is useful when a message has
- multiple forwarded message body parts because without it,
- the EncodedInformationType(s) of the component forwarded
- messages cannot be deduced easily. DeliveryInformation is
- useful for autoforwarded messages because the
- EncodedInformationType of an autoforwarded message is
- "unspecified" and the EncodedInformationType(s) of the
- message cannot be determined easily without it. Absence of
- the EncodedInformationType(s) makes it difficult for a UA to
- easily determine whether the message can be rendered.
-
- 7.12.2 RECOMMENDED PRACTICES IN RTS
-
- 1. In the case where S-U-ABORT indicates a temporaryProblem,
- reestablishment of the session should not be attempted for a
- "sensible" time period (typically not less than five
- minutes).
-
- In instances where this delay is not required or necessary,
- report a localSystemProblem.
-
- 2. S-U-EXCEPTION-REPORT reason codes can be interpreted as
- follows:
-
- o receiving ability jeopardized (value 1)
- Possible meaning: The receiving RTS knows of an
- impending system shutdown.
-
- o local ss-User error (value 5)
- Possible meaning: The receiving RTS needs to
- resynchronize the session dialogue.
-
- o irrecoverable procedure error (value 6)
- Possible meaning: The receiving RTS has had to delete
- a partially received APDU, even though some minor
- synchronization points have been confirmed.
-
- o non specific error (value 0)
- Possible meaning: The receiving RTS cannot handle the
- APDU (for example, because it was too large) and wishes
- to inform the sending RTS not to try again.
-
- o sequence error (value 3):
- Possible meaning: The S-ACTIVITY-RESUME request
- specified a minor synchronization point serial number
- which does not match the checkpoint data.
-
- 3. For purposes of identifying an MTA during an RTS Open, OSI
- addressing information should be used. This addressing
- information is conveyed by lower layer protocols and is
- reflected by the calling and called SSAP parameters of the
- S-CONNECT primitives.
-
- MTA validation and identification are related, but separate,
- functions. The mTAName and password protocol elements of
- the RTS user data should be used for validation, rather that
- identification, of an MTA. The RTS initiator and responder
- may independently require each other to supply mTAName and
- password.
-
- The CallingSSUserReference parameter of the S-CONNECT
- primitives should only have meaning to the entity that
- encoded it and should not be used to identify an MTA.
-
-
- 7.12.3 RECOMMENDED PRACTICES FOR ORName
-
- Table 7.9 stipulates that the StandardAttributeList must contain
- either PrivateDomainName or OrganizationName. It is recommended
- that, for both originator and recipients in a private domain, the
- PrivateDomainName field be used.
-
- It is recommended that there should be a DomainDefinedAttribute
- to be used in addressing UAs in existing mail systems, in order
- to curtail the proliferation of different types of
- DomainDefinedAttributes used for the same purpose. The syntax of
- this DomainDefinedAttribute conforms to the CCITT Pragmatic
- Constraints, and thus has a maximum value length of 128 octets
- and a type length of 8 octets, each of type Printable String.
- Only one occurrence is allowed.
-
- This DomainDefinedAttribute has the type name "ID" (in
- uppercase). It contains the unique identifier of the UA used in
- addressing within the domain. This DomainDefinedAttribute is to
- be exclusively used for routing within the destination domain
- (i.e., once routed to that domain via the mandatory components of
- the StandardAttributeList); any other components of the
- StandardAttributeList may be provided. If they conflict delivery
- is not made.
-
- The contents of this parameter need not be validated in the
- originating domain or any relaying domain, but simply transferred
- intact to the next MTA or domain.
-
- Class 2 and class 3 MTAs in a PRMD should allow administrators to
- decide the number of OrganizationalUnits that should appear in
- user names, instead of imposing a software controlled limit which
- is less than four. This is desirable because when two different
- vendors impose different limits on the number of
- OrganizationalUnits in a name, it becomes difficult for the
- administrator to choose a sensible naming scheme.
-
- There are existing mail systems that include a small set of non-
- Printable String characters in their identifiers. For these
- systems to communicate with X.400 messaging systems, either for
- pass-through service or delivery to X.400 users, gateways will be
- employed to encode these special characters into a sequence of
- Printable String characters. This conversion should be
- performed by the gateway according to a common scheme and before
- insertion in the ID DDA, which is intended to carry electronic
- mail identifiers. X.400 User Agents may also wish to perform
- such conversions.
-
- It is recommended that the following symmetrical encoding and
- decoding algorithm for non-Printable String characters be
- employed by gateways. The encoding algorithm maps an ID from an
- ASCII representation to a PrintableString representation. Any
- non-printable string characters not specified in the table are
- covered by the category "other" in the table below.
- The principal conversion table for the mapping is as follows:
-
- Table 7B.1 Printable string to ASCII mapping
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 ASCII Character Printable String Character 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 % (percent) (p) 3
- 3 @ (at sign) (a) 3
- 3 ! (exclamation) (b) 3
- 3 " (quote mark) (q) 3
- 3 _ (underline) (u) 3
- 3 ( (left paren.) (l) 3
- 3 ) (right paren.) (r) 3
- 3 other (3DIGIT) 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- where 3DIGIT has the range 000 to 377 and is interpreted as the octal
- encoding of an ASCII character.
-
- To encode an ASCII representation to a PrintableString, the table and the
- following algorithm should be used:
-
- IF current character is in the encoding set THEN
- encode the character according to the table above
- ELSE
- write the current character;
- continue reading;
-
- To decode a PrintableString representation to an ASCII representation,
- the table and the following algorithm should be used:
-
- IF current character is not "(" THEN
- write character
- ELSE
- {
- look ahead appropriate characters;
- IF composite characters are in the above table THEN
- decode per above table
- ELSE
- write current character;
- }
- continue reading;
-
- Class 2 and class 3 MTAs in a PRMD should allow administrators to
- decide the number of OrganizationalUnits that should appear in
- user names, instead of imposing a software controlled limit which
- is less than four. This is desirable because when two different
- vendors impose different limits on the number of
- OrganizationalUnits in a name, it becomes difficult for the
- administrator to choose a sensible naming scheme.
-
- 7.12.4 POSTAL ADDRESSING
-
- For domains wishing to support postal (or physical) delivery
- options, the following interim set of "nationally-defined" domain
- defined attributes are recommended. The CCITT will define
- Standard Attributes in support of physical delivery in its 1988
- Recommendations; this is only an interim solution.
-
- CCITT will also be addressing the services associated with
- physical delivery. This interim solution does not address the
- end-to-end service aspects of physical delivery; in particular,
- the following IPM service elements do not currently extend
- outside of the X.400 environment:
-
- o alternate Recipient Assignment
- o PROBE
- o Receipt Notification / Non-Receipt Notifications
- o Grade of delivery
-
- "Delivery" means passing a message from the MTS to the physical
- delivery system (PDS), and not to the user (or user agent).
-
- The following three DDAs are recommended to be used to specify a
- postal (or physical) address:
-
- CNTRPC - encodes the country and postal code for postal
- delivery. The DDA value is of the form
- "Country?Postalcode" (for example, "USA?22096"). The
- country field is optional, the postal code is
- optional; the separator ("?") is not. If both country
- and postal code are missing, this DDA should not be
- specified.
-
- PDA 1 - The country and postal code fields are free-form text.
-
- PDA 2 - These two DDA (signifying Postal Delivery Address
- strings 1 and 2) form a 256 character free-form
- postal address. Fields are separated by a question
- mark ("?"). There is no implied separator between
- PDA1 and PDA2. The meaning of the fields are defined
- by each domain supporting the physical delivery
- interface. PDA1 contains the first 128 characters,
- PDA2 the next 128 characters. If the PDA string is
- less than 128 characters, PDA2 is not used.
-
- For example, if the domain interprets the PDA fields as lines,
- the address
-
- Mr. John Smith
- Conway Steel
- 123 Main Street
- Reston VA 22096
-
- would be encoded as follows:
-
- type = "PDA1" value = "Mr. John Smith?Conway Steel?123 Main
- Street?Reston VA"
- CNTRPC = "?22096"
-
-
- 7.12.5 EDI use of X.400
-
- 7.12.5.1 Introduction and Scope
-
- This is a guideline for EDI data transfer in an X.400
- environment conforming to the NBS agreements. These
- recommended practices outline procedures for use in
- transferring EDI transactions between trading partner
- applications in an attempt to facilitate actual X.400
- implementation by EDI users.
-
- The scope of this guideline is to describe specific
- recommendations for adopting X.400 as the data transfer
- mechanism between EDI applications.
-
- 7.12.5.2 Model
-
- The MHS recommendations can accommodate EDI through the
- approach illustrated below. Many Message Transfer (MT)
- service elements defined in the X.400 recommendations are
- particularly useful to the EDI application.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 X.400 Message (1 EDI interchange) 3
- 3 ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3
- 3 3 3 3
- 3 3 ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 3
- 3 3 3 3 3 3
- 3 Envelope ------------------->3 P1 Control 3 3 3
- 3 3 3 Information 3 3 3
- 3 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY 3 3
- 3 3 3 3
- 3 3 3 3
- 3 3 3 3
- 3 3 ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 3
- 3 3 3 One 3 3 3
- 3 Content ------------------->3 EDI 3 3 3
- 3 3 3 Interchange 3 3 3
- 3 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY 3 3
- 3 3 3 3
- 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY 3
- 3 MHS Message 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- This diagram depicts an EDI content (1 EDI interchange)
- enveloped by the P1 MHS envelope. All the MT Services
- defined in the X.400 Recommendations may be used for EDI.
- However, it is not required to support optional or non-
- essential services to exchange EDI data between EDI users.
- When an EDI user submits an EDI Trade Document to the EDI
- User Agent, the EDI UA will submit the EDI content plus P1
- envelope to the Message Transfer System (MTS).
-
-
- ZDDDDDDDDDDD? ZDDDDDDDDDDDD? ZDDDDDDDDDDD?
- 3 3 3 EDI 3 3 EDI 3
- 3 MTS 3<----------->3 UA 3<------------>3 User 3
- 3 3 3 3 3 3
- @DDDDDDDDDDDY @DDDDDDDDDDDDY @DDDDDDDDDDDY
-
-
- The EDI UA must support the essential MT Services as defined
- in these Agreements; for example, as a minimum, to provide
- default values for services not elected by the EDI user,
- such as Grade of Delivery.
-
- Note: MT Services are not necessarily made available by the
- EDI UA to the EDI user.
-
-
- 7.12.5.3 Protocol Elements Supported for EDI
-
- The following P1 protocol elements will be used to support
- EDI applications:
-
- Content Type
- For EDI applications, the content type will be 0
- (undefined content).
-
- Original Encoded Information Types
- Any EIT defined in the X.400 Recommendations may be
- used to specify the encoding of EDI content. However,
- for ANSI X12 EDI applications in particular, it is
- expected that the "undefined" and "Ia5Text" EIT's will
- normally be used, with "undefined" used to signify the
- EBCDIC character set.
-
-
- 7.12.5.4 Addressing and Routing
-
- It is anticipated that connection of some existing systems
- to an X.400 service for EDI purposes will be by other than
- X.400 protocols, at least in the short term.
-
- EDI messages entering the X.400 environment will therefore
- need to have X.400 O/R Names added to identify the
- origination and recipient trading partners, typically by
- means of local directory services in the origination domain
- which will map EDI identifiers/addresses into O/R Names.
- Such O/R Names will contain Standard Attributes as defined
- in Table 7.9 and for recipient trading partners will at
- least identify the destination domain.
-
- In the case of trading partners outside the X.400
- environment, it is expected, however, that there will be
- cases where message delivery will require the provision of
- addressing information beyond that which can be carried in
- Standard Attributes. In such cases, Domain Defined
- Attributes are recommended to be used.
-
- The syntax of this DDA is as defined in Table 7.9, with a
- single occurrence having the type name "EDI" (uppercase) and
- a value containing the identifier/address of the trading
- partner. For ASC X12 purposes, specifically, this value
- will comprise the 2 digit interchange ID qualifier followed
- by the interchange ID (max 15 characters). Routing on this
- DDA shall only occur, if at all, in the destination domain.
-
- 7.12.6 USA Body Parts
-
- It is recommended that UAs can generate any USA Body Part, as
- defined in section 7.5.3.6.2, and that they can receive such body
- parts as well. reception of USA Body Parts does not imply
- further processing by the UA, but merely that the body part is
- made available, with a indication of its registered body part
- identifier, to another process or deposition in a file.
- Generation implies the reverse of this process.
- 7.13 APPENDIX C: RENDITION OF IA5Text AND T61String CHARACTERS
-
- 7.13.1 GENERATING AND IMAGING IA5Text
-
- The characters that may be used in an IA5String are the graphic
- characters (including Space), control characters and Delete of
- the IA5 character repertoire ISO 646.
-
- The graphic characters that may be used with a guaranteed
- rendition are those related with positions 2/0 to 2/2, 2/5 to
- 3/15, 4/1 to 5/10, 5/15 and 6/1 to 7/10 in the basic 7-bit code
- table.
-
- The other graphic characters may be used but have no guaranteed
- rendition.
-
- The control characters that may be used but have no guaranteed
- effect are a subset consisting of the format effectors 0/10 (LF),
- 0/12 (FF) and 0/13 (CR) provided they are used in one of the
- following combinations:
-
- CR LF to start a new line
- CR FF to start a new page (and line)
- LF .. LF to show empty lines (always after one of the
- preceding combinations).
-
- The other control characters or the above control characters in
- different combinations may be used but have no guaranteed effect.
-
- The character Delete may occur but has no guaranteed effect. The
- IA5String in a P2 IA5Text BodyPart represents a series of lines
- which may be divided into pages. Each line should contain from 0
- to 80 graphic characters for guaranteed rendition. Longer lines
- may be arbitrarily broken for rendition. Note that X.408 states
- that for conversion from IA5Text to Teletex, the maximum line
- length is 77 characters.
-
- 7.13.2 GENERATING AND IMAGING T61String
-
- For further study.
- 7.14 APPENDIX D: DIFFERENCES IN INTERPRETATION DISCOVERED THROUGH
- TESTING OF THE MHS FOR THE CeBit 87 DEMONSTRATION
-
- Several interworking problems were discovered through multi-vendor
- testing. These problems, and recommendations for solutions to them are
- discussed in this appendix.
-
- 7.14.1 ENCODING OF RTS USER DATA
-
- The password is defined as an ANY in the X.400 Recommendations,
- and implementor's groups have decided to use an IA5String for
- this field. There was some confusion about what the X.409
- encoding for this IA5String would be, and the correct encoding
- is:
-
- class: context specific
- form: constructor
- id code: 1
- length: length of contents
- contents: (primitive encoding)
- IA5String: 16
- length: length of contents
- contents: the password string
- class: context specific
- form: constructor
- id code: 1
- length: length of contents
- contents: (constructor encoding) left as an exercise for the
- reader
-
- Implementations should be prepared to receive any X.409 type for
- the password because of its definition as an ANY.
-
- 7.14.2 EXTRA SESSION FUNCTIONAL UNITS
-
- One vendor proposed more than the required set of functional
- units on opening the session connection, and the receiver
- rejected the connection. All debate aside about whether the
- initiator should have proposed units outside of the required set,
- or whether the receiver should have rejected the connection, the
- set of functional units can be negotiated in a straightforward
- way. The following is recommended.
-
- If the initiator proposes using more than the required set of
- functional units, the responder should specify the set of
- functional units that it would like to use (which should include
- the required set) in the open response. The session
- implementations will automatically use the intersection of the
- units proposed by both sides.
-
- If the initiator proposes using less than the required set of
- functional units, the responder should reject the connection.
- Unfortunately, there is not an appropriate RefuseReason for
- rejecting the connection, so instead of refusing the connection
- in the response to the S-CONNECT, the receiver should issue an S-
- U-ABORT with an AbortReason of protocolError. Note that it is
- valid to issue an S-U-ABORT instead of responding to the S-
- CONNECT. A problem report has been submitted to the CCITT
- requesting the addition of a RefuseReason for this situation.
-
- If the responder proposes using less than the required set of
- functional units, the session connection is established before
- the initiator can check for this. If too few functional units
- have been proposed, the initiator should abort the connection
- using S-U-ABORT, with an abort reason of protocolError.
-
- 7.14.3 MIXED CASE IN THE MTA NAME
-
- The MTA name is frequently exchanged over the telephone when two
- systems are being configured to communicate with one another. In
- one such telephone exchange, the casing of the MTA name was not
- specified, the MTA name consisted of both upper and lower case
- letters, and one of the implementations compared MTA names for
- equality in a case sensitive manner. Consequently, connections
- failed until the problem was detected and repaired. It is
- recommended that the MTA name be compared for equality in a case
- insensitive manner, and that the password be compared for
- equality in a case sensitive manner.
-
- 7.14.4 X.410 ACTIVITY IDENTIFIER
-
- The X.400 Implementor's Guide recommends that the activity
- identifier be X.409 encoded, but this is only a recommendation
- and not a requirement. Consequently, receiving systems cannot
- assume that the activity identifier will be X.409 encoded.
-
- 7.14.5 ENCODING OF PER RECIPIENT FLAG AND PER MESSAGE FLAG
-
- In the definition of the PerRecipientFlag in X.411, there is a
- statement that the last three bits are reserved, and should be
- set to zero. It is unclear whether those bits are unused in the
- X.409 encoding. Receivers should accept encodings with either
- zero or three unused bits. A problem report has been submitted
- to the CCITT asking for clarification.
-
- Though there is not any statement in X.411 about the last four
- bits of the PerMessageFlag, some vendors have encoded this with
- zero unused bits, and some have encoded it with four unused bits.
- The PerMessageFlag should be encoded with at least four unused
- bits.
-
- 7.14.6 ENCODING OF EMPTY BITSTRINGS
-
- There are three valid encodings for an empty bitstring: a
- constructor of length zero, a constructor of indefinite length
- followed by the end-of-contents terminator, and a primitive of
- length one with a zero octet as the value.
-
- 7.14.7 ADDITIONAL OCTETS FOR BITSTRINGS
-
- Nothing in X.409 constrains an implementation from sending two,
- three, four, or even more octets for a bitstring that fits into
- one octet, with the undefined bits set to zero. Note that the
- number of excess octets is bounded by the pragmatic constraints
- guidelines of the CCITT X.400 Implementor's Guide for all of the
- bitstrings in P1.
-
- 7.14.8 APPLICATION PROTOCOL IDENTIFIER
-
- If a value other that 1 is received in the applicationProtocol of
- the pUserData in the PConnect, NBS implementations will reject
- the connection. If CEN/CENELEC implementations receive a value
- other than 8883 for this field, they will reject the connection.
- This is an unfortunate state of affairs, because if NBS
- implementations accept the value of 8883 without supporting the
- MOTIS service elements, they would be misrepresenting themselves.
- To make matters worse, CEPT uses a value of 1, but relays MOTIS
- elements, which means that MOTIS elements will be relayed to
- implementations using a value of 1 to demonstrate that they do
- not support MOTIS. Work is continuing to try to find a solution
- that will allow European implementations to interwork with U.S
- implementations.
-
- 7.14.9 INITIAL SERIAL NUMBER IN S-CONNECT
-
- This should be implemented in accordance with section 3.5.1 E4 of
- the Implementors' Guide.
-
- 7.14.10 CONNECTION DATA ON RTS RECOVERY
-
- It is clarified that the ConnectionData is identical in both the
- S-CONNECT.request and the S-CONNECT.response. The value of the
- ConnectionData is the old Session Connection Identifier.
-
- 7.14.11 ACTIVITY RESUME
-
- If an activity is being resumed on a new session connection, it
- is not clear from X.410 and X.225 whether all four of the called-
- ss-user reference, the calling-ss-user reference, the common
- reference, and the additional reference information should be
- specified in the S-ACTIVITY-RESUME, or whether one of the ss-
- user-references should be absent. It is also unclear whether the
- called-ss-user reference should be identical to the calling-ss-
- user reference if both are present. Consequently, receivers
- should be tolerant of this situation. Appropriate problem
- reports will be submitted to the CCITT asking for clarification.
-
- 7.14.12 OLD ACTIVITY IDENTIFIER
-
- The Old Activity Identifier in S-ACTIVITY-RESUME refers to the
- original activity identifier.
-
- 7.14.13 NEGOTIATION DOWN TO TRANSPORT CLASS 0
-
- For European implementations, X.410 specifies that class 0
- transport must be supported. However, it is permissible for an
- initiator to propose a higher class as the preferred class,
- provided that class 0 appears as the alternate class in the T-
- Connect PDU. A responding implementation can choose to use
- either the preferred or alternate class, but again, must be able
- to use class 0. In other words, for private to private
- connections in Europe, class 0 transport is required.
-
- This conflicts with the NBS agreements, since class 0 is only
- required if one of the partners in a connection is an ADMD.7.15APPENDIX E:WORLDWIDE X.400 CONFORMANCE PROFILE MATRIX
-
- Y CONFORMANCE (E)
- implies a conformance problem for European products in the U.S.
-
- Y CONFORMANCE (US)
- implies a conformance problem for U.S. products in Europe.
-
- o The A/311 profile is specified in Env 41 202, the A/3211 profile
- in Env 41 201
-
- o No TTC protocol classification for RTS exists.
-
- o The notation X/Y indicates "X" for PRMDs and "Y" for ADMDs, i.e.
- "M/G" would be Mandatory for PRMDs and Generatable for ADMDs.
-
- Table 7E.1 Protocol element comparison of RTS
-
- ZDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDBDDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD?
- 3RTS element 3 NBS 3 A/311 3 A/3211 3 PROBLEM Y/N 3
- CDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDEDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDD4
- 3PConnect 3 M 3 M 3 M 3 N 3
- 3 DataTransferSyntax 3 M 0 3 M 0 3 M 0 3 N 3
- 3PUserData 3 M 3 M 3 M 3 N 3
- 3 checkpointSize 3 H 3 H 3 H 3 N 3
- 3 windowSize 3 H 3 H 3 H 3 N 3
- 3 dialogueMode 3 H 3 H 3 H 3 N 3
- 3 connectdata 3 M 3 M 3 M 3 N 3
- 3 applicationProtocol 3 G 1 3 H 1 3 R 8883 3 N 3
- 3 3 H 88833 3 3 3
- 3 ConnectionData 3 3 3 3 3
- 3 Open 3 G 3 G 3 G 3 N 3
- 3 Recover 3 G 3 H 3 G 3 N 3
- 3 3 3 3 3 3
- 3 Open 3 3 3 3 3
- 3 RTSUserData 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3
- 3 Recover 3 3 3 3 3
- 3 SessionConnectionID 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3
- 3RTSUserData 3 3 3 3 3
- 3 MTAName 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3
- 3 Password 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3
- 3 null 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3
- 3SessionConnectionID 3 3 3 3 3
- 3 CallingUserReference 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3
- 3 CommonReference 3 M 3 M 3 M 3 N 3
- 3 AdditionalRefInfo 3 H 3 H 3 H 3 N 3
- 3 3 3 3 3 3
- 3PAccept 3 G 3 G 3 G 3 N 3
- 3 DataTransferSyntax 3 M 0 3 M 0 3 M 0 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDADDDDDDDADDDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
- Table 7E.1 Protocol element comparison of RTS, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDBDDDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD?
- 3RTS element 3 NBS 3 A/311 3 A/3211 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDEDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3
- 3PUserData 3 M 3 M 3 M 3 N 3
- 3 CheckpointSize 3 H 3 H 3 H 3 N 3
- 3 WindowSize 3 H 3 H 3 H 3 N 3
- 3 ConnectionData 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3
- 3PRefuse 3 G 3 G 3 G 3 N 3
- 3 RefuseReason 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3
- 3SSUserData 3 G 3 G 3 G 3 N 3
- 3 (in S-TOKEN-PLEASE) 3 3 3 3 3
- 3 3 3 3 3 3
- 3AbortInformation 3 G 3 G 3 G 3 N 3
- 3 (in S-U-ABORT) 3 3 3 3 3
- 3 AbortReason 3 H 3 H 3 H 3 N 3
- 3 reflectedParameter 3 X 3 X 3 X 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDADDDDDDADDDDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDY
-
-
- Table 7E.2 Protocol element comparison of P1
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 ORname 3 3 3 3 3 3
- 3 StandardAttributeList 3 M 3 M 3 M 3 M 3 N See Note 4 3
- 3 DomainDefAttributeList 3 X 3 X 3 X 3 G 3 Y See Note 5 3
- 3 3 3 3 3 3 3
- 3 StandardAttributeList 3 3 3 3 3 3
- 3 CountryName 3 R 3 R 3 R 3 M 3 N 3
- 3 3 3ISO R 3 R 3 3 N 3
- 3 3 3X.121 H3 H 3 3 Y Conformance (E) 3
- 3 3 3Other X3 X 3 3 Y Prot Vio 3
- 3 AdministrationDomainName 3 R 3 R 3 G 3 M 3 N 3
- 3 ... if PrintableString 3 3 R 3 G 3 3 N 3
- 3 ... if numericString 3 3 H 3 H 3 3 Y Conformance (E) 3
- 3 X.121 Address 3 X 3 X/R 3 X 3 3Y Conf(US)See Note 13
- 3 Terminal ID 3 X 3 X/G 3 X 3 3Y Conf(US)See Note 13
- 3 PrivateDomainName 3 G 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3 3
- 3 OrganizationName 3 G 3 G 3 G 3 G 3 N 3
- 3 UniqueUAidentifier 3 X 3 X/G 3 X 3 3Y Conf(US)See Note 13
- 3 PersonalName 3 G 3 G 3 G 3 G 3 N 3
- 3 OrganizationalUnit 3 G 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3 3
- 3 DomainDefinedAttribute 3 X 3 X 3 X 3 G 3 N 3
- 3 Type 3 M 3 M 3 M 3 M 3 N 3
- 3 Value 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 PersonalName 3 3 3 3 3 3
- 3 Surname 3 M 3 M 3 M 3 M 3 N 3
- 3 GivenName 3 G 3 G 3 G 3 G 3 N 3
- 3 Initials 3 G 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3 3
- 3 GenerationQualifier 3 G 3 X 3 X 3 X 3 Y Conformance (E) 3
- 3 3 3 3 3 3 3
- 3 GlobalDomainIdentifier 3 3 3 3 3 3
- 3 CountryName 3 M 3 M 3 M 3 M 3 N 3
- 3 AdministrationDomainName 3 M 3 M 3 G 3 M 3 Y Proto Vio 3
- 3 PrivateDomainIdentifier 3 R/H 3 H 3 R 3 M/X 3 N 3
- 3 3 3 3 3 3 3
- 3 MPDU 3 3 3 3 3 3
- 3 UserMPDU 3 G 3 G 3 G 3 G 3 Y TTC required 3
- 3 3 3 3 3 3 MPDU size is 3
- 3 3 3 3 3 3 32K 3
- 3 DeliveryReportMPDU 3 G 3 G 3 G 3 G 3 N 3
- 3 3 3 3 3 3 3
- 3 ProbeMPDU 3 H 3 H 3 H 3 H 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
- Table 7E.2 Protocol element comparison of P1, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 UserMPDU 3 3 3 3 3 3
- 3 UMPDUenvelope 3 M 3 M 3 M 3 M 3 N 3
- 3 UMPDUcontent 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 UMPDUenvelope 3 3 3 3 3 3
- 3 MPDUidentifier 3 M 3 M 3 M 3 M 3 N 3
- 3 originatorORname 3 M 3 M 3 M 3 M 3 N 3
- 3 originalEncodedTypes 3 G 3 H 3 H 3 G 3 Y Conformance (E)3
- 3 3 3 3 3 3 3
- 3 ContentType 3 M 3 M 3 M 3 M 3 N 3
- 3 UAcontentID 3 H 3 H 3 H 3 H 3 N 3
- 3 Priority 3 G 3 G 3 G 3 G 3 N 3
- 3 PerMessageFlag 3 G 3 G 3 G 3 G 3 N 3
- 3 DeferredDelivery 3 X 3 X 3 X 3 X 3 N 3
- 3 PerDomainBilatInfo 3 X 3 X 3 X 3 X 3 N 3
- 3 RecipientInfo 3 M 3 M 3 M 3 M 3 Y TTC MPDU 32K 3
- 3 TraceInformation 3 M 3 M 3 M 3 M 3 N 3
- 3MOTIS-> LatestDelivery 3 3 3 X 3 3 N 3
- 3MOTIS-> InternalTraceInfo 3 M/P 3 3 P 3 3 N 3
- 3 UMPDUcontent 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 MPDUidentifier 3 3 3 3 3 3
- 3 GlobalDomainIdent 3 M 3 M 3 M 3 M 3 N 3
- 3 IA5string 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 PerMessageFlag 3 3 3 3 3 3
- 3 DiscloseRecipients 3 H 3G @ MTL3 H 3 H 3 Y Conformance (US)3
- 3 3 3H at UA3 ? 3 3 Y Conformance (US)3
- 3 ConversionProhibited 3 G 3 G 3 G 3 G 3 N 3
- 3 AlternatRecipAllowed 3 H 3G @ MTL3 H 3 X 3 Y Conformance (US)3
- 3 3 3H at UA3 ? 3 3 Y Conformance (US)3
- 3 ContentReturnRequest 3 X 3 X 3 X 3 X 3 3
- 3MOTIS-> redirectionProhibited 3 3 3 X 3 3 N 3
- 3 3 3 3 3 3 3
- 3 PerDomainBilateralInfo 3 3 3 3 3 3
- 3 CountryName 3 M 3 M 3 M 3 M 3 N 3
- 3 AdminDomainName 3 M 3 M 3 G 3 M 3 Y Prot Vio 3
- 3MOTIS-> PrivateDomainName 3 3 3 G 3 3 N 3
- 3 BilateralInfo 3 M 3 M 3 M 3 M 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
- Table 7E.2 Protocol element comparison of P1, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3 DeliveryReportContent 3 3 3 3 3 3
- 3 original MPDUident 3 M 3 M 3 M 3 M 3 N 3
- 3 intermediate Trace 3 X/G 3 X 3 X 3 X 3 Y Conformance (E) 3
- 3 UAcontentID 3 G 3 G 3 G 3 G 3 N 3
- 3 ReportedRecipientInfo 3 M 3 M 3 M 3 M 3 Y TTC 256 max 3
- 3 returned 3 H 3 H 3 X 3 X 3 Y Conformance (E) 3
- 3 billing information 3 X 3 X 3 X 3 X 3 N 3
- 3 3 3 3 3 3 3
- 3 ReportedRecipientInfo 3 3 3 3 3 3
- 3 recipient ORname 3 M 3 M 3 M 3 M 3 N 3
- 3 extensionsIdentifier 3 M 3 M 3 M 3 M 3 N 3
- 3 PerRecipientFlag 3 M 3 M 3 M 3 M 3 N 3
- 3 LastTraceInformation 3 M 3 M 3 M 3 M 3 N 3
- 3 intendedRecipient 3 H 3 H 3 H 3 H 3 N 3
- 3 SupplementaryInfo 3 X/H 3 X 3 X 3 X 3 Y Conformance (E) 3
- 3MOTIS-> ReassignmentInfo 3 3 3 X 3 3 N 3
- 3 3 3 3 3 3 3
- 3MOTIS-> ReassignmentInfo 3 3 3 3 3 3
- 3MOTIS-> intendedRecipient 3 3 3 M 3 3 N 3
- 3MOTIS-> reasonForReassignment 3 3 3 H 3 3 N 3
- 3 3 3 3 3 3 3
- 3 LastTraceInformation 3 3 3 3 3 3
- 3 arrival 3 M 3 M 3 M 3 M 3 N 3
- 3 convertedEncInfoTypes 3 G 3 G 3 H 3 G 3 Y Conformance (E) 3
- 3 Report 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 Report 3 3 3 3 3 3
- 3 DeliveredInfo 3 G 3 G 3 G 3 D? 3 N See Note 6 3
- 3 3 3 3 3 CDM 3 3
- 3 NonDeliveredInfo 3 G 3 G 3 G 3 DY 3 N 3
- 3 3 3 3 3 3 3
- 3 DeliveredInfo 3 3 3 3 3 3
- 3 delivery 3 M 3 M 3 M 3 M 3 N 3
- 3 TypeofUA 3 R/H 3 H 3 R 3 M/G 3 N 3
- 3 3 3 3 3 3 3
- 3 NonDeliveredInfo 3 3 3 3 3 3
- 3 ReasonCode 3 M 3 M 3 M 3 M 3 N 3
- 3 DiagnosticCode 3 H 3 H 3 H 3 H 3 N 3
- 3MOTIS-> UAprofileIdentifier 3 3 3 X 3 3 N 3
- 3 3 3 3 3 3 3
- 3MOTIS-> UAprofileIdentifier 3 3 3 3 3 3
- 3MOTIS-> ContentType 3 3 3 M 3 3 N 3
- 3MOTIS-> EncodedInfoTypes 3 3 3 M 3 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7E.2 Protocol element comparison of P1, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 ProbeEnvelope 3 3 3 3 3 3
- 3 probe 3 M 3 M 3 M 3 M 3 N 3
- 3 originator 3 M 3 M 3 M 3 M 3 N 3
- 3 ContentType 3 M 3 M 3 M 3 M 3 N 3
- 3 UAcontentID 3 H 3 H 3 H 3 H 3 N 3
- 3 originalEncInfoTypes 3 G 3 H 3 H 3 G 3 Y Conformance (E) 3
- 3 TraceInformation 3 M 3 M 3 M 3 M 3 N 3
- 3 PerMessageFlag 3 G 3 G 3 G 3 G 3 N 3
- 3 ContentLength 3 H 3 H 3 H 3 H 3 N 3
- 3 PerDomainBilatInfo 3 X 3 X 3 X 3 X 3 N 3
- 3 RecipientInfo 3 M 3 M 3 M 3 M 3 Y TTC 256 max 3
- 3MOTIS-> InternalTraceInfo 3 M/P 3 3 P 3 3 N 3
- 3 3 3 3 3 3 3
- 3 RecipientInfo 3 3 3 3 3 3
- 3 RecipientORname 3 M 3 M 3 M 3 M 3 N 3
- 3 ExtensionIdentifier 3 M 3 M 3 M 3 M 3 N 3
- 3 PerRecipientFlag 3 M 3 M 3 M 3 M 3 N 3
- 3 ExplicitConversion 3 X 3 X 3 X 3 X 3 N 3
- 3MOTIS-> OriginatorReqAlternatRecip3 3 3 X 3 3 N 3
- 3MOTIS-> ReassignmentInfo 3 3 3 X 3 3 N 3
- 3 3 3 3 3 3 3
- 3 PerRecipientFlag 3 3 3 3 3 3
- 3 ResponsibilityFlag 3 M 3 M 3 M 3 M 3 N 3
- 3 ReportRequest 3 M 3 M 3 M 3 M 3 N 3
- 3 UserReportRequest 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 TraceInformation 3 3 3 3 3 3
- 3 3 3 3 3 3 3
- 3 GlobalDomainIdent 3 M 3 M 3 M 3 M 3 N 3
- 3 DomainSuppliedInfo 3 M 3 M 3 M 3 M 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
- Table 7E.2 Protocol element comparison of P1, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 DomainSuppliedInfo 3 3 3 3 3 3
- 3 arrival 3 M 3 M 3 M 3 M 3 N 3
- 3 deferred 3 X 3 X 3 X 3 X 3 N 3
- 3 action 3 M 3 M 3 M 3 M 3 N 3
- 3 (0=relayed) 3 G 3 G 3 G 3 3 N Note: 3
- 3 3 3 3 3 3 Re-routing not 3
- 3 3 3 3 3 3 required. 3
- 3 (1=rerouted) 3 H 3 H 3 H 3 3 N 3
- 3MOTIS-> (2=recipientReassigned) 3 3 3 H 3 3 N 3
- 3 converted 3 H 3 G 3 H 3 H 3 Y Conformance(US)3
- 3 previous 3 H 3 G 3 G 3 X 3 Y Conformance(US)3
- 3 3 3 3 3 3 (Note: G is 3
- 3 3 3 3 3 3 inconsistent with3
- 3 3 3 3 3 3 action (relayed) 3
- 3 3 3 3 3 3 being "H".) 3
- 3 3 3 3 3 3 3
- 3 ORname 3 3 3 3 3 3
- 3 3 3 3 3 3 3
- 3 EncodedInformationTypes 3 3 3 3 3 3
- 3 BitString 3 M 3 M 3 M 3 M 3 N See Note 3 3
- 3 G3NonBasicParameters 3 X 3 X 3 X 3 X 3 N 3
- 3 TeletexNonBasicParams 3 X 3 R 3 X 3 X 3 Y Conformance(US)3
- 3 PresentationAbilities 3 X 3 X 3 X 3 X 3 N 3
- 3 3 3 3 3 3 3
- 3 DeliveryReportMPDU 3 G 3 G 3 M 3 G 3 N 3
- 3 DeliveryReportEnvelop 3 M 3 M 3 M 3 M 3 N 3
- 3 DeliveryReportContent 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 DeliveryReportEnvelope 3 3 3 3 3 3
- 3 report 3 M 3 M 3 M 3 M 3 N 3
- 3 originator ORname 3 M 3 M 3 M 3 M 3 N 3
- 3 TraceInformation 3 M 3 M 3 M 3 M 3 N 3
- 3 InternalTraceInfo 3 M/P 3 3 P 3 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
- Table 7E.3 Protocol element comparison of P2
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P2 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 UAPDU 3 3 3 3 3 3
- 3 IM_UAPDU 3 G 3 G 3 G 3 G 3 N 3
- 3 SR_UAPDU 3 X 3 X 3 X 3 X 3 N 3
- 3 3 3 3 3 3 3
- 3 IM_UAPDU 3 3 3 3 3 3
- 3 Heading 3 M 3 M 3 M 3 M 3 N 3
- 3 Body 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 Heading 3 3 3 3 3 3
- 3 IPmessageID 3 M 3 M 3 M 3 M 3 N 3
- 3 Originator ORname 3 R 3 R 3 R 3 M/G 3 N 3
- 3 AuthorizingUsers 3 H 3 H 3 H 3 H 3 Y TTC 16 max 3
- 3 PrimaryRecipients 3 G 3 G 3 G 3 G 3 Y TTC 256 max 3
- 3 CopyRecipients 3 G 3 G 3 G 3 G 3 Y TTC 256 max 3
- 3 BlindCopyRecipients 3 H 3 H 3 H 3 H 3 Y TTC 256 max 3
- 3 InReplyTo 3 G 3 G 3 G 3 G 3 N 3
- 3 Obsoletes 3 H 3 H 3 H 3 H 3 Y TTC 8 max 3
- 3 CrossReferences 3 H 3 H 3 H 3 H 3 Y TTC 8 max 3
- 3 Subject 3 G 3 G 3 G 3 G 3 N 3
- 3 ExpiryDate 3 H 3 H 3 H 3 H 3 N 3
- 3 ReplyBy 3 H 3 H 3 H 3 H 3 N 3
- 3 ReplyToUsers 3 H 3 H 3 H 3 H 3 Y TTC 32 max 3
- 3 Importance 3 H 3 H 3 H 3 H 3 N 3
- 3 Sensitivity 3 H 3 H 3 H 3 H 3 N 3
- 3 Autoforwarded 3 H 3 H 3 H 3 H 3 N 3
- 3MOTIS-> CirculationList 3 3 3 X 3 3 N 3
- 3MOTIS-> ObsoletingTime 3 3 3 X 3 3 N 3
- 3 3 3 3 3 3 3
- 3 IPmessageID 3 3 3 3 3 3
- 3 ORname 3 H 3 H 3 H 3 H 3 N 3
- 3 PrintableString 3 M 3 M 3 M 3 M 3 N 3
- 3 3 3 3 3 3 3
- 3 ORdescriptor 3 3 3 3 3 3
- 3 ORname 3 H 3 H 3 H 3 D? 3 N See Note 6 3
- 3 3 3 3 3 CDM 3 3
- 3 FreeFormName 3 H 3 H 3 H 3 DY 3 N 3
- 3 TelephoneNumber 3 H 3 H 3 H 3 G 3 N 3
- 3 3 3 3 3 3 3
- 3 Recipient 3 3 3 3 3 3
- 3 ORdescriptor 3 M 3 M 3 M 3 M 3 N 3
- 3 ReportRequest 3 X 3 X 3 X 3 X 3 N 3
- 3 ReplyRequest 3 H 3 H 3 H 3 H 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
- Table 7E.3 Protocol element comparison of P2, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P2 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3MOTIS-> CirculationList 3 3 3 3 3 3
- 3MOTIS-> CirculationMember 3 3 3 X 3 3 N 3
- 3MOTIS-> checkmark 3 3 3 M 3 3 N 3
- 3MOTIS-> membername 3 3 3 M 3 3 N 3
- 3 3 3 3 3 3 3
- 3MOTIS-> OBsoletingTime 3 3 3 3 3 3
- 3MOTIS-> Time 3 3 3 H 3 3 N 3
- 3MOTIS-> IP_MessageID 3 3 3 H 3 3 N 3
- 3 3 3 3 3 3 3
- 3 Body 3 3 3 3 3 3
- 3 BodyPart 3 G 3 M 3 M 3 G 3 Y Conformance (US)3
- 3 3 3 3 3 3 3
- 3 SR_UAPDU 3 3 3 3 3 3
- 3 NonReceipt 3 H 3 H 3 H 3 D? 3 N 3
- 3 3 3 3 3 CDM 3 3
- 3 Receipt 3 H 3 H 3 H 3 DY 3 N 3
- 3 Reported 3 M 3 M 3 M 3 M 3 N 3
- 3 ActualRecipient 3 R 3 R 3 R 3 G 3 N 3
- 3 IntendedRecipient 3 H 3 H 3 H 3 H 3 N 3
- 3 Converted 3 X 3 X 3 X 3 G 3 N 3
- 3MOTIS-> CirculationStatus 3 3 3 X 3 3 N 3
- 3 3 3 3 3 3 3
- 3 NonReceiptInformation 3 3 3 3 3 3
- 3 Reason 3 M 3 M 3 M 3 M 3 N 3
- 3 NonReceiptQualifier 3 H 3 H 3 H 3 H 3 N 3
- 3 =expired (value) 3 0 3 0 3 0 3 0 3 N 3
- 3 =obsoleted (value) 3 1 3 1 3 1 3 1 3 N 3
- 3 =subscriptionTerminated 3 2 3 2 3 2 3 2 3 N 3
- 3MOTIS-> =timeobsoleted (value) 3 3 3 X 3 3 N 3
- 3 Comments 3 H 3 H 3 H 3 X 3 N 3
- 3 returned 3 H 3 X 3 X 3 X 3 Y Conformance (E) 3
- 3 3 3 3 3 3 3
- 3 ReceiptInformation 3 3 3 3 3 3
- 3 Receipt 3 M 3 M 3 M 3 M 3 N 3
- 3 TypeOfReceipt 3 H 3 H 3 H 3 G 3 N 3
- 3 SupplementaryInfo 3 X 3 X 3 X 3 X 3 N 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
- (Continued on next page.)
-
- Table 7E.3 Protocol element comparison of P2, continued
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
- 3P2 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 BODYPART SUPPORT 3 3 3 3 3 3
- 3 3 3 3 3 3 3
- 3 o IA5 Text 3 G 3 G 3 G 3 3 N See Note 7 3
- 3 o TLX 3 X 3 X 3 X 3 3 N 3
- 3 o Voice 3 X 3 X 3 X 3 3 N 3
- 3 o G3FAX 3 X 3 X 3 X 3 3 N 3
- 3 o TIFO 3 X 3 X 3 X 3 3 N 3
- 3 o TTX 3 X 3 X/H 3 X 3 3Y Conf(US)See Note 23
- 3 o VideoTex 3 X 3 X 3 X 3 3 N 3
- 3 o NationallyDefined 3 X 3 X 3 X 3 3 N 3
- 3 o Encrypted 3 X 3 X 3 X 3 3 N 3
- 3 o ForwardedIPmessage 3 H 3 H 3 H 3 3 N 3
- 3 o SFD 3 X 3 X 3 X 3 3 N 3
- 3 o TIFI 3 X 3 X 3 X 3 3 N 3
- 3 3 3 3 3 3 3
- 3MOTIS-> o ODA 3 3 3 X 3 3 N 3
- 3MOTIS-> o ISO6937 Text 3 3 3 H 3 3 N 3
- 3 3 3 3 3 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
-
- Note 1: It should be noted that the A/311 profile states: For routing
- all ADMDs should support all Form 1 Variants of O/R Name. All
- PRMDs should support at least Form 1, Variant 1 form of OR Name.
-
- Note 2: It should also be noted that the A/311 profile requires that all
- ADMDs should support the reception of Teletex body parts for
- delivery to their own UAEs.
-
- Note 3: An A/3211 implementation may generate MOTIS encoded information
- types. See 7.6.11.
-
- Note 4: Only Form 1 Variant 1 of O/Rname shown for TTC, but TTC defines
- other forms and variants. Form 1 Variant 1 recommended for PRMDs
- and ADMDs, Form 1 Variant 2 also recommended for ADMDs.
-
- Note 5: DDA's can be used to specify recipients in any Japanese domains
- other than TTC. Assignment of DDAs for UAs within TTC domains is
- not recommended.
-
- Note 6: One of [DeliveredInfo/NonDeliveredInfo] must be present. TTC
- encodes this as shown. Other profiles represent this by
- classifying both protocol elements as generatable. A similar
- situation exists with the P2 ORdescriptor.
-
- Note 7: TTC is expected to support IA5 for some international MHS
- communications.
- 7.16 APPENDIX F: INTERWORKING WARNINGS
-
- ADMD name is to be encoded as a single space when configurations with
- no ADMD's are present. It should be noted that this may change in
- January 1988 so that the ADMD name is encoded as a zero length element
- in such cases.
-
- The NBS agreements allow implementation to generate MPDUs with no
- body parts. Such MPDUs will be rejected by European-conformant
- systems. (Note this situation may change in January 1988)
-
- In order to optimize the number of recipients you can read and reply
- to, it is advisable to be able to generate all standard O/R name
- attributes.
-
- 8. DIRECTORY SERVICES PROTOCOLS
-
- 8.1 INTRODUCTION
-
- This is an Implementation Agreement developed by the Implementor's
- Workshop sponsored by the U.S. National Bureau of Standards to promote
- the useful exchange of data between devices manufactured by different
- vendors. This agreement is based on and employs protocols developed
- in accord with the OSI Reference Model. While this agreement
- introduces no new protocols, it eliminates ambiguities in
- interpretations.
-
- This is an Implementation Agreement for Directories based on the ISO
- documents cited in the Reference Section 11.1 (hereafter referenced as
- Directory documents). Versions of this document will stay consistent
- with the latest drafts of those Directory Documents. Figure 8.1
- displays the structure of this Implementation Agreement. References
- to corresponding CCITT documents are included for information.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Directory Access Protocol 3 Directory System Protocol 3
- 3 (DAP) 3 (DSP) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 Remote Operations Services and Protocols 3
- 3 (CCITT X.219 and X.229/ISO 9072/1 and 9072/2) 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
- 3 Association Control Services and Protocols 3
- 3 (CCITT X.217 and X.227/ISO 8649 and 8650) 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Figure 8.1 Structure of this Implementation Agreement
-
-
- The Directory User Agents (DUAs) and Directory System Agents (DSAs)
- provide access to the Directory on behalf of humans and applications
- such as Message Handling and File Transfer, Access, and Management.
- See the Scope and Field of Application section for more information on
- the model used in Directories.
-
- This document covers both the Directory Access Protocol (DAP) and the
- Directory System Protocol(DSP) defined in the Directory documents. A
- good working knowledge of the Directory documents is assumed by this
- chapter. All terminology and abbreviations used but not defined in
- this text may be found in those documents.
-
-
- 8.2 SCOPE AND FIELD OF APPLICATION
-
- Centralized and distributed directories can both be accommodated in
- this Agreement by the appropriate choice of protocols and pragmatic
- constraints from those specified. Figure 8.2 illustrates a
- centralized directory and Figure 8.3 illustrates a distributed
- directory.
-
- This agreement does not cover interaction between co-located entities,
- such as a co-resident DUA and DSA. It also does not specify the
- interface between a user (person or application) and a DUA.
- Bilateral agreements between a DUA and DSA or DSA and DSA may be
- implemented in addition to the requirements stated in this document.
- Conformance to this agreement requires the ability to interact
- without the use of bilateral agreements other than those required in
- the Directory documents.
-
- The logical structure of the Directory Information Base (DIB) is
- described in the Directory documents. The manner in which a local
- portion of the DIB is organized and accessed by its DSA is not in the
- scope of this agreement.
-
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 00000000000000000000000 3
- 3 0 The Directory 0 3
- 3 0 0 3
- 3 0 ZDDDDDDDDDDD? 0 3
- 3 ZDDDDDDDDDDD? ZDDDDDDDDDD? 0 3 3 0 3
- 3 3 USER 3<DDD>3 DUA 3<DDD0DDD>3 3 0 3
- 3 @DDDDDDDDDDDY @DDDDDDDDDDY 0 3 DSA 3 0 3
- 3 ZDDDDDDDDDDD? ZDDDDDDDDDD? 0 3 3 0 3
- 3 3 USER 3<DDD>3 DUA 3<DDD0DDD>3 3 0 3
- 3 @DDDDDDDDDDDY @DDDDDDDDDDY 0 @DDDDDDDDDDDY 0 3
- 3 0 0 3
- 3 0 0 3
- 3 00000000000000000000000 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Figure 8.2 Centralized Directory Model
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 ZDDDDDDD? 3
- 3 3 User 3 3
- 3 @DDDBDDDY 3
- 3 3 3
- 3 ZDDDADDD? 3
- 3 3 DUA 3 3
- 3 @DDDBDDDY 3
- 3 3 3
- 3ZDDDDDD? ZDDDDDDD?0000000000000000000000000000000 3
- 33 User CDD4 DUA 30The Directory 3 0 3
- 3@DDDDDDY @DDDDDDDY0 3 0 3
- 3 0 ZDDDADDD? 0 3
- 3 0 3 DSA 3 0 3
- 3 0 @DDDDDDDY 0 3
- 3 0ZDDDDDDD? ZDDDDDDD?0 3
- 3 03 DSA 3 3 DSA 30 3
- 3 0@DDDDDDDY @DDDDDDDY0 3
- 3ZDDDDDD? ZDDDDDDD?0 ZDDDDDDD? 0ZDDDDDDD? ZDDDDDD?3
- 33 User CDD4 DUA 30 3 DSA 3 03 DUA CDD4 User 33
- 3@DDDDDDY @DDDDDDDY0 @DDDDDDDY 0@DDDDDDDY @DDDDDDY3
- 3 0000000000000000000000000000000 3
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Figure 8.3 Distributed Directory Model
-
-
- 8.3 STATUS
-
- This version was completed on December 18, 1987.
-
-
- 8.4 Use of Directories
-
- Given the rapid multiplication and expansion of OSI applications,
- telecommunication systems and services, there is growing need for
- users of, as well as the applications themselves, to communicate with
- each other. In order to facilitate their communications, a Directory
- protocol, as referenced in these agreements, has been tailored to meet
- their respective needs.
-
- In one instance, Directories will be used as a service to provide
- humans, in an on-line fashion, rapid and easy retrieval of information
- useful for determining what telecommunications services are available,
- and/or how to access, and address their correspondents. Further,
- service providers offering such a Public Directory may also use this
- service internally with other various telecommunications services
- (e.g., MHS) for the proper addressing of calls or messages. Likewise,
- this does not preclude the usage of these agreements to similarly
- generate a privately operated Directory that supports both human and
- application information exchanges.
-
- In another instance, Directories, will be used as a service by
- computer applications without direct human involvement. One important
- service is to provide Presentation Address resolution for named
- objects, on behalf of OSI applications. The directory may be used by
- applications to search for objects (i.e., Application Entities),
- without direct human involvement, by the use of the "search" or
- "list" operations.
-
- To support the many possible usages, the Directory is a general
- purpose system. It is capable of storing data of many different
- forms as attributes within entries, and is also capable of supporting
- simple or complex hierarchical structures, with variations in
- structure possibly occurring between one part of the Directory and
- another.
-
- Compliant DSA implementations should safeguard this generality, where
- possible, by placing the minimum of restrictions in "hard-wired"
- form. The Directory permits the imposition of rules by means of the
- Directory Schema (Section 8.6 below); but the Directory Schema
- itself should be capable of alteration by Directory management.
-
-
- 8.5 Directory ASEs, Application Contexts, and Ports
-
- The following section is included for tutorial purposes. The
- functionality of the Directory AEs (DUAs and DSAs) is defined by a set
- of ASEs, each Directory ASE specifying a set of Directory operations.
-
- The interaction between these AEs is described in terms of their use
- of ASEs. This specific combination of a set of ASEs and the rules for
- their usage defines an application context.
-
- Thus, each Directory application context defines the operations needed
- by two communicating Directory entities.
-
- Access to the services provided by an application context is through
- one or more directory ports. The point of access is called an Access
- Point (see Figure 8.4). Each access point corresponds to a
- particular combination of port types.
-
- The following ASEs are described in the Directory Document:
-
- o Directory Read ASE
- o Directory Chained Read ASE
- o Directory Search ASE
- o Directory Chained Search ASE
- o Directory Modify ASE
- o Directory Chained Modify ASE
-
- ROSE and ACSE also form part of the Directory Application Contexts.
-
- The following Application Contexts are described in the Directory
- Document:
-
- o Directory Access Application Context
- o Directory System Application Context
-
-
- The following Ports are described in the Directory Document:
-
- o Read Port
- o Modify Port
- o Search Port
- o Chained Read Port
- o Chained Search Port
- o Chained Modify Port
-
- The ports cited above are to be specified for a particular Access
- Point to the Directory as illustrated by Figure 8.4.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 Access Point DDDDDDDDD? 3
- 3 3 3
- 3 ZDDDDDDDDDDDDDDDD? 3ZDDDDDDDDDDDDDDD? 3
- 3 3 3 33 3 3
- 3 3 Directory ZDDDDADDDDD? 33 3 3
- 3 3 user 3 3 3 The 3 3
- 3 3 3 DUA CDDDDDDDDDDDDD4 Directory 3 3
- 3 3 3 3 3 3 3
- 3 3 @DDDDBDDDDDY 3 3 3
- 3 3 3 3 3 3
- 3 @DDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDY 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Figure 8.4 Access to the Directory
-
-
-
- 8.6 Schemas
-
- There are four (4) major topics that relate to schemas:
-
- 8.6.1 Maintenance of Structures and Naming Rules
-
- DSAs shall be capable of supporting the object classes and the
- associated structure and naming rules defined in the Directory
- documents, part 7, annex B, in the sense that DITs may be
- constructed and within these rules shall be supported.
-
-
- 8.6.2 Maintenance of object classes and subclasses
-
- DSAs shall be able to support the storage and use of the
- following object classes defined in the Directory documents part
- 7, annex B:
-
- top alias
- country application entity
- locality organizational-person
- organization residential-person
- organizational unit application-process
- DSA
-
- Use of the modification and local extension mechanisms provided
- by registered and unregistered object classes is optional.
-
-
- 8.6.3 Maintenance of Attribute Types
-
- DSAs shall be able to support the storage and use of attribute
- type information, as defined in Part 6, including their use in
- naming and access to entries; they shall also support the
- definition of new attribute types, making use of pre-existing
- attribute syntaxes.
-
-
- 8.6.4 Maintenance of Attribute Syntaxes
-
- Suggested methods for the interpretation of selected Attribute
- Syntaxes are defined in Appendix B.
-
-
- 8.7 Classification of Support for Attribute Types
-
- This section classifies directory support for selected attribute type
- specified in the Directory documents.
-
- Classification of support for selected attribute types is either
- mandatory or optional.
-
-
- 8.7.1 Mandatory Support
-
- The Directory must be able to support these Attribute Types:
-
- Aliased Object Name Postal Address
- Business Category Postal Code
- Common Name Preferred Delivery Mode
- Country Name Presentation Address
- Locality Name Role Occupant
- ISDN Address See Also
- Member Serial Number
- Object Class State or Province Name
- Organization Name Street Address
- Organizational Unit Name Supported Application Context
- Owner Surname
- Post Office Box Telephone Number
- Title
- User Password
- X.121 Address
-
-
- Note: Support of these Attribute Types implies full support
- of the relevant Attribute Syntaxes.
-
-
- 8.7.2 Optional Support
-
- Directory support of these attribute types is considered
- optional:
-
- Authority Revocation List
- CA Certificate
- Certificate Revocation List
- Description
- Destination Indicator
- Facsimile Telephone Number
- Knowledge Information
- Non-Basic Parameters
- Physical Delivery Office Name
- Registered Address
- Search Guide
- Teletex Terminal Identifier
- Telex Number
- User Certificate
-
-
-
- Note: DSAs should consider initial support of the Attribute
- Syntax relevant to any Attribute Type for which future
- support is planned, in addition to those required for
- mandatory Attribute Types.
-
-
- 8.8 Introduction to Pragmatic Constraints
-
- The following sections of this document define the pragmatic
- constraints to which a conformant implementation must adhere in
- addition to those specified in the Directory documents. The pragmatic
- constraints are divided into two areas. The first includes those
- aspects of pragmatic constraints which apply to the scope of service.
- The second includes those aspects of pragmatic constraints which are
- specific to particular attribute types.
-
-
- 8.9 General Constraints
-
-
- 8.9.1 Character Sets
-
- It is a requirement to support all character sets and other name
- forms defined in the Directory Documents Part 6. Those
- character sets include:
-
- o T.61
- o PrintableString
- o NumericString
-
-
- 8.9.2 APDU Size Considerations
-
- In the process of chaining requests it is possible that a
- chaining DSA may receive invoke or return APDUs that exceed its
- capacity:
-
-
- ZDDDDDDDDD? 2k ZDDDDDDDDD? 2k ZDDDDDDDDD?
- 3 CDDDDDDDDDDDDDD>3 CDDDDDDDDDDDDDDD>3 3
- 3 DUA 3 3 DSA 3 3 DSA 3
- 3 3<DDDDDDDDDDDDDD4 ZDE<DDDDDDDDDDDDDDD4 3
- @DDDDDDDDDY 37K @DDDDDDDEDY 33K @DDDDDDDDDY
- DSA may pass on DSA may discard
-
-
- Figure 8.5 APDU Exchange
-
-
- It is a minimum requirement that invoke and return result APDUs
- must be accepted unless they exceed 32767 octets in size; in
- this case they may be discarded as illustrated in the right side
- of figure 8.5, and an "unwillingToPerform" error reporting
- service shall be used.
-
-
- 8.9.3 Service Control (SC) Considerations
-
- This agreement recognizes that DUAs may automatically supply
- defaults for any SC parameter. The choice of default values
- selected (if any) is seen to be a matter of local policy and
- consumer needs.
-
-
- 8.9.4 Priority Service Control
-
- Priority is specified as a service control argument in the
- Directory documents. The following statements represent a
- clarification of the semantics that may be used by a DSA in
- interpreting and operating on this parameter.
-
- The logical model in Figure 8.6 may be considered as an example
- by DSAs that implement this Service Control.
-
- o The DSA maintains three logical queues corresponding to
- the three priority levels.
-
- o The DSA Scheduler is separate and distinct from any
- scheduling function provided by the underlying
- operating system or control program services.
-
- o The DSA Scheduler presents jobs to the Underlying
- Operating Services for execution and always presents
- jobs of a higher priority before those of a lower
- priority.
-
- o The DSA Scheduler will not preempt a request once it
- has been passed to the underlying operating system
- service.
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3 ZDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDD? 3
- 3 ZDDD>3 High CDDDDD>3 3
- 3 3 @DDDDDDDDDDDDDDDDY 3 ZDDDDDDDDDDD? 3
- 3 3 ZDDDDDDDDDDDDDDDD? 3 3 DSA 3 3
- 3 CDDD>3 Medium CDDDDD>3 3 Scheduler 3 3
- 3 3 @DDDDDDDDDDDDDDDDY 3 @DDBDDDDDDDDY 3
- 3 3 ZDDDDDDDDDDDDDDDD? 3 3 3
- 3 CDDD>3 Low CDDDDD>3 3 3
- 3 3 @DDDDDDDDDDDDDDDDY 3
- 3ZDDADDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDD? 3
- 33 Underlying 3 3 Underlying OS 3 3
- 33 Protocol Services 3 3 Services 3 3
- 3@DDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDY 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
- Figure 8.6 Logical DSA Application Environment
-
-
- 8.10 Constraints on Operations
-
- There are no overall constraints upon service arguments or results
- except those implied in section 8.9.2 of this document.
-
-
- 8.10.1 Filters
-
- It is required that DSAs, at a minimum, support 8 nested
- "Filter" parameters, and a total limit of 32 Filter Items. If
- these limits are exceeded, the recipient of that SearchArgument
- may return the ServiceProblem "unwillingToPerform".
-
-
- 8.10.2 Errors
-
- There are no constraints upon any Error service except the APDU
- size limit as defined in section 8.9.2.
-
- 8.11 Constraints on Attribute Types
-
- This section defines the pragmatic constraints specific to particular
- attribute types.
-
-
- 8.11.1 Attribute Values
-
- This section describes the pragmatic constraints for attribute
- values. Each constraint is given in terms of a Length
- Constraint. The Length Constraint for a given attribute value is
- the number of units which a sending entity must not exceed and
- which a receiving entity must accept and process. A sending
- entity need not be capable of sending attribute values as large
- as the Length Constraints.
-
- Use of Pragmatic Constraints for Strings
-
- The Length Constraint for strings is expressed as the number of
- allowable characters and the number of allowable octets. When
- using the Printable String ASN.1 data type, the number of octets
- equals the number of characters. When using the T.61 ASN.1 data
- type, the number of octets is twice the number of characters.
- This is because some T.61 characters occupy two octets per
- character.
-
- Attribute Types
-
- Table 8.1 specifies the pragmatic constraints for selected
- attribute types specified in the Directory documents; many of
- these constraints also appear and are the same in the CCITT
- version of the Directory documents.
-
- Alphabets
-
- T.61 Strings used as attribute values shall only encode graphic
- characters and spaces. (They must not contain formatting
- characters (such as subscript) or other control characters.
-
- Table 8.1 Pragmatic Constraints for Selected Attributes.
-
- ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
- 3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
- 3 3 3 of 3 of 3 3 3
- 3 3 3 Print- 3 Allow- 3 3 3
- 3 3 3 able 3 able 3 3 3
- 3 3 3 Char- 3 Octets 3 3 3
- 3 3 3 acters 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Object Class 3 Object 3 3 256 3 3 3
- 3 3 Identifier3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Common Name 3 T.61 or 3 64 3 128 3 3 X.500 3
- 3 3 Printable 3 3 3 3 3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Serial Number 3 Printable 3 64 3 64 3 3 X.500 3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Country Name 3 Printable 3 3 3 3 ISO 3166 3
- 3 3 String 3 2 3 2 3 3 String only 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Locality 3 T.61 or 3 128 3 256 3 3 X.500 3
- 3 3 Printable 3 3 3 3 3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Postal 3 T.61 or 3 30 x 6 3 60 x 6 3 3 Note 4 3
- 3 Address 3 Printable 3 3 3 3 X.500 & UPU 3
- 3 3 String 3 3 3 3 3
- 3 3 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Postal Code 3 T.61 or 3 40 3 80 3 3 UPU 3
- 3 3 Printable 3 3 3 3 X.500 3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Organization 3 T.61 or 3 64 3 128 3 3 X.500 3
- 3 Name 3 Printable 3 3 3 3 3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Organizational 3 T.61 or 3 64 3 128 3 3 X.500 3
- 3 Unit Name 3 Printable 3 3 3 3 3
- 3 3 String 3 3 3 3 3
- @DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
-
- Table 8.1 Pragmatic Constraints for Selected Attributes. (continued)
-
- ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
- 3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
- 3 3 3 of 3 of 3 3 3
- 3 3 3 Print- 3 Allow- 3 3 3
- 3 3 3 able 3 able 3 3 3
- 3 3 3 Char- 3 Octets 3 3 3
- 3 3 3 acters 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Title 3 T.61 or 3 64 3 128 3 3 X.500 3
- 3 3 Printable 3 3 3 3 3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Description 3 T.61 or 3 1024 3 2048 3 3 X.500 About 3
- 3 3 Printable 3 3 3 3 1 Screen full3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Search Guide 3 3 3 3 3 ffs 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Business Category3 T.61 or 3 64 3 128 3 3 3
- 3 3 Printable 3 3 3 3 3
- 3 3 String 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Facsimile Tele- 3 Facsimile 3 3 ffs 3 3 CCITT E.163 3
- 3 phone Number 3 Telephone 3 3 3 3 X.500 3
- 3 3 Number 3 3 3 3 Includes G3 3
- 3 3 3 3 3 3 Non Basic 3
- 3 3 3 3 3 3 Parameters 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 ISDN Address 3 Numeric 3 n/a 3 16+40 3 3 CCITT 3
- 3 3 String 3 3 3 3 E. 164 X.500 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Presentation 3 Presen- 3 n/a 3 224 3 3Note 2,ISO 74983
- 3 Address 3 tation 3 3 3 3X.500, & X.200 3
- 3 3 Address 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Telephone 3 Printable 3 32 3 32 3 3 CCITT E.163 3
- 3 Number 3 String 3 3 3 3 X.500 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Teletex Terminal 3 Teletex 3 3 ffs 3 3 CCITT F.200 3
- 3 Identifier 3 Terminal 3 3 3 3 X.500 3
- 3 3 Identifier3 3 3 3 Includes 3
- 3 3 3 3 3 3 Teletex Non 3
- 3 3 3 3 3 3 Basic 3
- 3 3 3 3 3 3 Parameters 3
- @DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
-
- Table 8.1 Pragmatic Constraints For Selected Attributes. (continued)
- ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
- 3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
- 3 3 3 of 3 of 3 3 3
- 3 3 3 Print- 3 Allow- 3 3 3
- 3 3 3 able 3 able 3 3 3
- 3 3 3 Char- 3 Octets 3 3 3
- 3 3 3 acters 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 3 Telex 3 3 3 3 CCITT X.500 3
- 3 Telex Number 3 Number 3 3 ffs 3 3 X.121 3
- 3 3 3 3 3 3 Contains 3
- 3 3 3 3 3 3 telex-number,3
- 3 3 3 3 3 3 country code,3
- 3 3 3 3 3 3 answer back 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 X.121 Address 3 Numeric 3 15 3 15 3 3 CCITT X.121 3
- 3 3 3 3 3 3 X.500 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Member 3 Distin- 3 3 3 3 Note 3 3
- 3 3 guished 3 3 3 3 3
- 3 3 Name 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Owner 3 Distin- 3 3 3 3 Note 3 3
- 3 3 guished 3 3 3 3 3
- 3 3 Name 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Role 3 Distin- 3 3 3 3 Note 3 3
- 3 Occupant 3 guished 3 3 3 3 3
- 3 3 Name 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 See Also 3 Distin- 3 3 3 3 Note 3 3
- 3 3 guished 3 3 3 3 3
- 3 3 Name 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 User 3 Octet 3 n/a 3 128 3 3X.500 Allow 3
- 3 Password 3 String 3 3 3 3long passwords.3
- 3 3 3 3 3 3Machine 3
- 3 3 3 3 3 3Generated 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Aliased Object 3 Distin- 3 3 3 3 Note 3 3
- 3 Name 3 guished 3 3 3 3 3
- 3 3 Name 3 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 Knowledge 3 T.61 or 3 1024 3 2048 3 3 About 1 3
- 3 Information 3 Printable 3 3 3 3 screen full. 3
- 3 3 String 3 3 3 3 ffs 3
- @DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
- Table 8.1 Pragmatic Constraints For Selected Attributes. (continued)
- ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
- 3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
- 3 3 3 of 3 of 3 3 3
- 3 3 3 Print- 3 Allow- 3 3 3
- 3 3 3 able 3 able 3 3 3
- 3 3 3 Char- 3 Octets 3 3 3
- 3 3 3 acters 3 3 3 3
- CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
- 3 3 3 3 3 3 3
- 3 Street Address 3 T.61 or 3 3 3 3UPU. Component 3
- 3 3 Printable 3 3 3 3of Postal 3
- 3 3 String 3 3 3 3Address 3
- @DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
-
-
- Notes:
-
- 1. The pragmatic constraints of these parameters are defined in
- other standards. We will accommodate these values in our
- pragmatic constraints.
-
- 2. Presentation address is composed of "X" NSAP addresses, and
- three selectors, (20X + 32 + 16 + 16 ), e.g. if X = 1, this would
- be 84. These numbers are based on the most recent implementor's
- agreements. With 8 NSAP addresses this value is 224.
-
- 3. Pragmatic constraints are only applied to the individual
- components of DistinguishedName as defined in the Directory
- Documents Part 2. Not all components of a DN will necessarily be
- understood by an implementation.
-
- 4. Implementors should be aware that constraints on Postal Address
- may not be sufficient for some markets.
-
-
- 8.12 Conformance
-
- The following sections will describe various aspects of Directory
- conformance. It should be noted that conformance to the various ASEs
- and conformance to the Authentication Framework are viewed as separate
- issues and are presented in that context.
-
-
- 8.12.1 DUA Conformance
-
- Conformance requirements for DUAs are adequately specified in the
- Directory documents, Part 5, section 9.1. It should be noted
- that DUA conformance can only be demonstrated by exercising the
- interface that it provides to its user.
-
- It is recognized that DUAs will be widely differing in nature:
-
- o Some are intended to support human users, some application
- users
-
- o Particular DUAs may not support particular operations
- because the application that they support has no
- requirement; others will be general purpose, and will
- support all operations.
-
- o Some DUAs will have a fixed view of the Directory content
- and structure, reflecting the usage of the Directory by a
- particular application; others will have a more flexible
- view which can be adapted to new usages.
-
- o Some DUAs will provide automatic referral services with
- automatic establishment and release of associations; others
- will place the burden on the user.
-
- o Some DUAs will provide a variety of authentication means;
- others will support simple authentication only
-
- o Some DUAs will handle operations synchronously; others will
- have the capability of maintaining several identifiable
- dialogues with the Directory at one time.
-
- No general implementation agreements are spelled out in respect
- of these possibilities.
-
-
- 8.12.2 DSA Conformance
-
- Basic conformance requirements for a DSA are defined in the
- Directory documents, Part 5, section 9.2.
-
- Centralized
-
- A centralized DSA is defined as one that contains its entire
- relevant DIT; it follows that it will not make use of the DSP or
- generate referral responses. Since this model only contains a
- single DSA it is not subject to DSA interworking issues and will
- always provide a consistent level of service and results. A
- centralized DSA must be fully "protocol" conformant to the DAP.
-
- Cooperating
-
- In a distributed directory, responsibility for various portions
- of the DIT may be "distributed" among multiple DSAs. On a per
- operation basis we define a DSA to be "holding" when it is
- responsible for the fragment of the DIB in which a given entry
- will appear if it exists; we define a DSA to be "propagating"
- when it is unable to complete the name resolution process. All
- DSAs must be capable of acting as a "holder" and a"propagator."
-
-
- 8.12.3 Directory Systems Conformance Classes
-
- A DSA implementation shall satisfy the conformance requirements
- as defined in the Directory documents, part 5, section 9.2, and
- shall support the "Versions" argument of "Bind".
-
- Additionally, an implementation conformant to these agreements
- shall state which of the following conformance classes it
- implements:
-
- Conformance Class 0: Centralized Directory
-
- A DSA implementation conformant to this class only supports the
- DirectoryAccessAC. It must implement all operations in the Read
- and Modify ASEs. Optionally, it may implement the operations in
- the Search ASE.
-
- A DSA that does not support the Search and List operations must
- reply to such operations with an unwillingToPerform service
- error.
-
- Conformance Class 1: Distributed Directories
-
- A DSA implementation conformant to this class must implement all
- the operations in the ASEs that are part of the Application
- context for which it claims conformance. It must support the
- DirectoryAccessAC and it may optionally support the
- DirectorySystemAC.
-
- 8.12.4 Authentication Conformance
-
- A Directory System may choose to implement various levels of
- authentication (Directory documents, Part 8). We define the
- following four (4) levels of authentication in the DS:
-
- o No authentication at all; (None)
-
- o Identification of the remote peer entity only, without
- verification; (Weak)
-
- o Simple authentication: verified identification with or
- without a password. Intended to make masquerading
- difficult; and
-
- o Strong authentication: identification with verification
- using cryptographic techniques intended to make
- masquerading, in practical terms, nearly impossible.
-
- The Authentication Framework document describes the specific goal
- of each authentication level; we have listed several practical
- uses of the various levels:
-
- NONE No authentication may be required for associations with
- a DSA containing public information: DSAs operating on
- a private network in a controlled environment may
- implicitly trust all connections and have no
- requirement for authentication.
-
- WEAK authentication may be desired to maintain access
- statistics or in a private network where the initiator
- is implicitly trusted and there is no need to incur
- the additional overhead of more sophisticated
- authentication methods.
-
- SIMPLE authentication may be necessary in situations where
- strong authentication is not practical, (i.e.:
- international connections, no knowledge of algorithms
- in use, etc).
-
- STRONG authentication will be required for secure
- environments.
-
-
- 8.12.5 Authentication Conformance Classes
-
- We define the following two (2) conformance classes for the
- support of authentication:
-
- o None, Weak,
- o None, Weak, and Simple (unprotected)
-
- Consideration of protected simple and strong authentication is
- not part of this agreement.
-
- 8.13 Distributed Operations
-
- The following requirements apply to DSAs supporting distributed
- operations:
-
- 1. DSAs must support the generation of referrals.
-
- 2. DSAs may additionally support chaining. DSAs that only support
- chaining (i.e. no referrals) are not allowed.
-
- 3. DSAs supporting authentication (e.g. simple authentication by
- name and password) must be able to invoke DSP operations to carry
- out authentication by reference to other DSAs. Thus all such
- DSAs must support the DSP protocol.
-
-
- 8.13.1 Referrals and Chaining
-
- It is recommended that a DSA which has chained a request act upon
- any referrals it receives rather that returning them to the
- requestor if the "PreferChaining" service control is present.
-
-
- 8.14 Underlying Services
-
-
- 8.14.1 ROSE
-
- It should be noted that support of "abandon" implies support of
- operation class 2.
-
-
- 8.14.2 Session
-
- All directory implementations are required to support Session
- Version 2.
-
- 8.15 Access Control
-
- Guidelines relation to access control can be found in annex F of the
- Directory documents, part 2.
-
- 8.16 Authentication
-
- Simple Authentication, as defined in Part 8 of the Directory
- documents, encompasses both Weak and Simple Authentication, as called
- for by section 8.12. (This shall be taken to imply unprotected simple
- authentication.)
-
- A DSA that implements Simple Authentication as called for in section
- 8.12, will check a user password, (if one is supplied) by means of a
- compare operation on the user's entry or otherwise; if no user
- password is supplied, the DSA will validate the presence of an entry
- for the user, by a read operation or otherwise; the authentication
- will fail if the password is incorrect, or if the user's entry does
- not exist. DSP must be used when the user's entry is not a local
- entry; this form of authentication is therefore not normally
- appropriate for DAP only DSAs.
-
- A DSA that implements Weak Authentication will accept simple
- credentials without validating them.
-
-
- 8.17 Test Considerations
-
- This section outlines some items that implementors may wish to
- consider in terms of testing expectations; additionally, future
- conformance testers may wish to consider these items when developing
- tests.
-
- 8.17.1 Major elements of Architecture
-
- One important aspect of testing is to confirm the correct
- behavior of DSAs and DUAs in respect of major elements of the
- directory architecture.
-
- Such major elements include:
-
- o Conformance Statement
-
- o Distinguished names (e.g., name resolution, equivalence of
- various forms)
-
- o Entries and Attributes (e.g., accessibility by operations,
- compliance with rules)
-
- o Handling of distributed operations (e.g.,naming contexts
- and knowledge)
-
- o Schemas
-
- - Structure rules (e.g., storage and maintenance of
- structure and of naming)
-
- - Object classes and sub-classes (e.g., storage and
- extension of rules for object attributes)
-
- - Attribute types (e.g., storage and maintenance of
- syntax classes and rules for multi or single valued
- attributes)
-
- - Attribute syntax (e.g. maintenance and support for
- attribute value testing and matching, to specification
- for a defined set of attribute types)
-
- o Operations
-
- - all operations
-
- - correct function
-
- - correct result
-
- - correct responses
-
- o Aliases (e.g., correct resolution, error responses)
-
- o Authentication and Access Control (e.g., limitation of
- modify access)
-
- o ROSE (e.g., correct handling of invokes, results, rejects,
- and invoke ids)
-
- o ACSE (e.g., association establishment / refusal for invalid
- application contexts, etc.)
-
-
- 8.17.2 Search Operation
-
- Testing of support for filter items should be reasonable. It is
- not expected that DSAs will be able to handle worst case testing
- in this area.
-
-
- 8.18 Errors
-
- This section provides clarification of the semantics of various
- operation errors and implementation guidelines on their usage.
-
-
- 8.18.1 Permanent vs. Temporary Service Errors
-
- The usage of the Service Errors busy, unavailable and
- unwillingToPerform requires some clarification:
-
- The error busy is particularly transient. It is returned when
- one or more of the Directory's internal resources are being used
- to their capacity and, hence, the requested operation cannot, for
- the moment, be performed. The Directory should be able to
- recover from this type of resource depletion after a short while.
-
- The error unavailable is also temporary but somewhat less
- transient. It indicates that the Directory (or some part of it)
- is currently unavailable and may continue to be unavailable for
- a reasonably long period of time. for example, this error is
- returned when a given DSA is functionally disabled, or when a
- specific part of the DIB is undergoing reconfiguration.
-
- The error unwillingToPerform has a permanent connotation. It
- indicates that the Directory cannot perform the requested
- operation because it would require resources beyond its capacity.
- For example, this error may be returned by a DSA if, satisfying a
- requested would result in the generation of an APDU in excess of
- 32767 octets.
- 8.19 APPENDIX A Definitions
-
- Any definitions not found in this appendix can be found in the
- Directory Documents.
-
- o Holding
-
- o Propagating
-
- o Centralized
-
- o Cooperating
- 8.20 APPENDIX B Attributes and Object Classes
-
- The Contents of this section are incomplete. Additional work
- describing algorithms related to schemas and special attribute types
- should be placed here.
-
- The attribute types defined in the Directory documents, Part 6, and
- listed in table 8.1 have requirements for underlying algorithms which
- relate:
-
- 1. To the checking of attribute values from the viewpoint of
- syntactical correctness and compliance with pragmatic
- constraints.
-
- 2. To the comparison of attribute values for the purpose of
- comparison (for equality, for matching substrings, and as a
- preliminary for determining relative ordering)
-
- Sections B.1 and B.2 give brief characteristics of the checking and
- comparison algorithms, respectively. These characteristics are not
- currently defined explicitly in the Directory documents. Section B.3
- summarizes their applicability to the attribute syntaxes defined by
- the Directory documents.
-
- It should be noted that determining relative ordering requires the
- application of a further algorithm appropriate to the type of value
- which requires ordering.
-
- B.1 Checking Algorithms
-
- Note. A particular attribute type in some cases defines more than one
- alternative attribute syntax. In this case, an attribute value is
- satisfied if it satisfies at least one checking algorithm, as listed
- below; maximum and minimum sizes may be specified for the attribute-
- syntax or the attribute type.
-
- B.1.1 T.61 String Check
-
- Checks that the value has the type code for T.61 string, that it
- encodes a sequence of valid T.61 characters, and that it complies with
- a maximum character length, if this is specified. Only graphic
- characters (including spaces) are permitted.
-
- B.1.2 Printable String Check
-
- Checks that the value has the type code for Printable String, and that
- it encodes as a sequence of valid printable string characters, and
- that it complies with a maximum character length, if this is
- specified.
-
- B.1.3 Numeric String Check
-
- Checks that the value has the type code for numeric string, that it
- encodes a sequence of valid numeric string characters, and that it
- complies with a maximum character length, if this is specified.
-
- B.1.4 Distinguished Name Check
-
- Checks that the value is a valid ASN.1 encoding for Distinguished
- name, and that for each known attribute type (i.e. that is registered
- in the DSA) each attribute value satisfies the appropriate checking
- algorithm.
-
- B.1.5 Object Identifier Check
-
- Checks that the type is correct. It is further study whether the
- value itself can be validated further.
-
- B.1.6 Criteria Check
-
- Checks that the value is a valid ASN.1 encoding for Criteria. It is
- for further study whether the value itself can be validated further.
-
- B.1.7 Presentation Address Check
-
- Checks that the value is a valid ASN.1 encoding for Presentation
- Address, and that each field is within the size limits appropriate to
- the field.
-
- B.1.8 Telephone Number Check
-
- For further study.
-
- B.1.9 Telex Number Check
-
- For further study.
-
- B.1.10 Facsimile Telephone Number Check
-
- Checks that the value of the first element is a valid telephone number
- (B.1.8), and that the second element is a valid ASN.1 encoding for
- Facsimile G3 Non-Basic Parameters.
-
- B.1.11 Teletex Terminal Identifier Check
-
- Checks that the value of the first element is a valid Printable String
- (B.1.2), and that the second element is a valid ASN.1 encoding for
- Teletex Non-Basic Parameters.
-
- B.1.12 Integer Check
-
- Checks that the value has integer type, and lies between defined or
- default integer values.
-
- B.1.13 String List Check
-
- Checks that each component is compliant using T.61 String Check or
- Printable String Check.
-
- B.1.14 Preferred Delivery Method Check
-
- For further study.
-
- B.1.15 Octet String Check
-
- No checking.
-
- B.1.16 Country Check
-
- Checks that the value is a 2-character string complaint with IS 3166
- codes only.
-
- B.2 Matching Algorithms
-
- Note: Matching algorithms are conveniently defined in terms of a
- two step process.
-
- 1. Take the checked reference value and the value to be matched, and
- reduce them to a canonical (i.e. standard) form (normalization),
- if necessary.
-
- 2. Carry out the comparison in the specified way (e.g. equality,
- substrings or ordering)
-
- Important Note
-
- The brief descriptions below outline the first step. The algorithms
- may be replaced, in a particular implementation, by equivalent
- procedures.
-
- B.2.1 String Match
-
- All the specific algorithms below carry out the following basic
- normalization: remove leading and trailing spaces; intermediate
- multiple spaces become single spaces. For example
- "[sp]Time[sp][sp]Flies[sp][sp]" becomes "Time[sp]Flies".
-
- B.2.2 Case Ignore String Match
-
- The basic normalization just described is carried out; in addition
- each lower case letter is converted to its upper case form. The ASN.1
- value is compared octet by octet, disregarding type. It is possible
- in this way to compare, for example, T.61 strings with Printable
- Strings.
-
- B.2.3 Case Exact String Match
-
- As above, but without the lower case to upper case conversion.
-
- B.2.4 ASN.1 Match
-
- The ASN.1 is converted to a standardized encoding forms, such as that
- given in Part 8 of the Directory documents, section 8.6.
-
- Two ASN.1 values may then be compared octet by octet, including the
- initial ASN.1 type. No matching for substrings or order is possible.
-
- B.2.5 Distinguished Name Match
-
- As for ASN.1 match, except that for each AVA within the distinguished
- name, normalization takes place (possibly recursively) in accordance
- with the nature of the attribute type.
-
- B.2.6 Case Ignore List Match
-
- Each component must match as for Case Ignore String Match.
-
- B.2.7 Criteria Match
-
- For further study.
-
- B.2.8 Telephone Number Match
-
- For further study.
-
- B.2.9 Telex Number Match
-
- For further study.
-
- B.3 Mapping of Attribute Syntaxes
-
- The following table maps the attribute syntaxes of Part 6 of the
- Directory documents, to the algorithms described in B.1 and B.2 :
-
- Syntax 3Check 3Match
- DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
- 3 3
- undefined 3None 3None
- caseExactStringSyntax 3T.61 String Check or 3Case Exact String Match
- 3Printable String Check 3
- caseIgnoreStringSyntax 3T.61 String Check or 3Case Ignore String Match
- 3Printable String Check 3
- caseIgnoreListSyntax 3String List Check 3Case Ignore List Match
- numericStringSyntax 3Numeric String Check 3Case Exact String Match
- printableStringSyntax 3Printable String Check 3Case Exact String Match
- distinguishedNameSyntax 3Distinguished Name Check 3Distinguished Name Match
- objectIdentifierSyntax 3Object Identifier Check 3No normalization
- criteriaSyntax 3Criteria Check 3Criteria Match
- presentationAddressSyntax 3Presentation Address Check3Presentation Address Match
- telephoneNumberSyntax 3Telephone Number Check 3Telephone Number Match
- telexNumberSyntax 3Telex Number Check 3Telex Number Match
- countrySyntax 3Country Check 3Case Ignore String Match
- integerSyntax 3Integer Check 3No normalization
- octetStringSyntax 3Octet String Check 3No normalization
- 3 3
-
- 8.21 APPENDIX C The Use of ROSE
-
- The use of ROSE by the BIND and UNBIND macros as described in the
- Directory documents, part 5, clause 8.2 will be used with no
- additional agreements.
- 8.22 APPENDIX D Guidelines
-
- The following guidelines were used to provide a general mechanism for
- arriving at pragmatic constraints within the Directory. These are
- included for the reader's information.
-
- 1. Align with other activities
-
- 2. Catch outlandish behavior
-
- o Infinite Loops
-
- o Runaway Process
-
- 3. Conserve Resources and Promote Efficiency
-
- o Memory
- o CPU
- o Bandwidth
- o Effort
-
- 4. Compromise Arbitrary Opinions
-
- 5. Police Actions / Catch Violators
-
- o Protect the Network
-
- 6. Facilitate Interworking
-
- 7. Syntax Interpretation
-
- o Errors
-
- 8. Set practical limits for the purpose of testing 8.23 APPENDIX EGlossary
-
- The following abbreviations may be useful; not all are used within
- these agreements.
-
- ACL Access Control List
- ACSE Association Control Service Element
- ADDMD Administration Directory Management Domain
- AETitle Application Entity Title
- APDU Application Protocol Data Unit
- ASE Application Service Element
- ASN.1 Abstract Syntax Notation - 1
- AVA Attribute Value Assertion
- B-RM Basic Reference Model
- CA Certification Authority
- CCITT Consultative Committee on International Telegraph &
- Telephone
- CEN Committee for European Normalization
- CENELEC Committee for European Normalization Electronique
- CEPT Committee European Postal & Telephonique
- COS Corporation for Open Systems
- DAP Directory Access Protocol
- DIB Directory Information Base
- DIT Directory Information Tree
- DMD Directory Management Domains
- DSA Directory System Agent
- DSP Directory System Protocol
- DUA Directory User Agent
- EWOS European Workshop for Open Systems
- FTAM File Transfer, Access & Management
- INTAP Interoperability Technical Association for Information
- Processing, Japan
- ISDN Integrated Services Digital Network
- ISO International Organization for Standardization
- KT Knowledge Tree
- LL Lower layers of OSI model (layers 1-4)
- MAP Manufacturing Automation Protocol
- MHS Message Handling Systems
- NBS National Bureau of Standards
- NSAP Network Services Access Point
- OSI Open Systems Interconnection
- PKCS Public Key Crypto System
- POSI Promotion for Open System Interconnection
- PRDMD Private Directory Management Domain
- PSAP Presentation Service Access Point
- RDN Relative Distinguished Name
- ROSE Remote Operations Service Element
- SIG Special Interest Group
- SPAG Standards Promotion & Application Group
- TOP Technical and Office Protocols
- UL Upper layers of OSI model (layers 5-7)
- UPU Universal Postal Union
- 9. SECURITY
-
- The Security Architecture specified in ISO 7498/Part 2 - Security
- Architecture (as presented in ISO/TC 97/SC 21/N1528) shall be used as a
- basis for further work in the Special Interest Group on Security.
-
- The security services that are to be implemented first shall include
- confidentiality, integrity, authentication and access control. Non-
- repudiation of the source shall also be included for consideration for
- implementation. These services are defined and discussed in more detail
- in ISO 7498/Part 2 - Security Architecture.
-
-
- 9.1 Definitions
-
- The following definitions, based on the definitions in ISO 7498/Part2,
- are to be used when interpreting Chapter 9.
-
- Access Control: The provision of a security system
- that establishes and enforces which
- users or processes can get access
- to what data or processing
- facilities.
-
- Authentication
- Information: Information used to establish the
- validity of a claimed identity.
-
- Authorization: The granting of access rights.
-
- Confidentiality: A security service that protects
- data from unauthorized disclosure.
-
- Connection: A state of communication that
- exists between two communicating
- entities by establishing an
- association between them, providing
- one or more data paths between them
- allowing sequential transfers of
- data, and then terminating the
- association.
-
- Connectionless: A state of communication that
- provides transfer of data from one
- entity to another without a
- preestablished association.
-
- Data Integrity: The property that data has not been
- altered or destroyed in an
- unauthorized manner.
-
- Data Origin
- Authentication: The corroboration that the source
- of data received is as claimed.
-
- Digital Signature: Data that allows a recipient of
- information to verify the source
- and integrity of the information.
-
- Peer-entity
- Authentication: The corroboration that peer
- entities in an association are as
- claimed.
-
- Repudiation: Denial by one or both of the
- entities of an association of
- having participated in all or part
- of the association or
- communication of the association.
-
- Selective Field
- Protection: The protection of specified fields
- of data in a communication.
-
- Traffic Analysis: The inference of information from
- observation of traffic flow in
- communications (presence, absence,
- amount, direction and frequency).
-
- Traffic Flow
- Confidentiality: A confidentiality service to
- protect against traffic analysis.
-
-
- 9.2 Matrix of Security Services and OSI Layers
-
- The following matrix shows the layers of the OSI architecture at which
- certain security services are considered to be desirable. The entries
- in the matrix are "H" for high level of desirability, "M" for medium
- desirability, and "L" for low level of desirability. No entry in the
- matrix means that the service is not considered desirable. This
- matrix was produced from a similar matrix in ISO 7498/Part 2 which
- showed the layers of the architecture that could be used to provide
- the security service. The level of desirability was established by
- the members of the Special Interest Group in Security of the OSI
- Implementors Workshop.
-
-
- Note: The Matrix is a consensus of the opinions of the members as to
- where selected security services should be placed. It should not be
- considered restrictive and interpreted as meaning that the security
- services cannot be placed elsewhere in the OSI architecture or have
- other implementation priorities. This will depend upon the differing
- security needs of specific applications. Also, it should not be
- considered complete in that other security services may exist that
- should be incorporated in the architecture.
-
-
-
- Table 9.1 OSI Layers Desirable for Placing Security
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDBDDDBDDDBDDDBDDDBDDDBDDD?
- 3 SERVICE 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3
- CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDEDDDEDDDEDDDEDDDEDDDEDDD4
- 3 3 3 3 3 3 3 3 3
- 31.(a) Peer entity authentication 3 3 3 L 3 H 3 3 3 H 3
- 3 (b) Data origin authentication 3 3 3 L 3 L 3 3 3 H 3
- 3 3 3 3 3 3 3 3 3
- 32. Access Control Service 3 Authorization Model 3 3
- 3 3 3 3 3 3 3 3 3
- 33.(a) Connection confidentiality 3 L 3 L 3 L 3 H 3 3 H 3 H 3
- 3 (b) Connectionless confidentiality 3 3 L 3 H 3 L 3 3 H 3 H 3
- 3 (c) Selective field confidentiality 3 3 3 3 3 3 H 3 H 3
- 3 (d) Traffic flow confidentiality 3 M 3 3 L 3 3 3 3 L 3
- 3 3 3 3 3 3 3 3 3
- 34.(a) Connection integrity with recovery 3 3 3 3 H 3 3 3 L 3
- 3 (b) Connection integrity without recovery 3 3 3 No Plan 3 3 3
- 3 (c) Selective field connection integrity 3 3 3 No Plan 3 3 3
- 3 (d) Connectionless integrity 3 3 3 H 3 L 3 3 3 L 3
- 3 (e) Selective field connectionless integrity3 3 3 3 3 3 3 H 3
- 3 3 3 3 3 3 3 3 3
- 35.(a) Non-repudiation: originator 3 3 3 3 3 3 3 L 3
- 3 (b) Non-repudiation: receiver 3 3 3 3 3 3 3 L 3
- 3 3 3 3 3 3 3 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDADDDADDDADDDADDDADDDADDDY
-
- Implementation priority: H (high)
- M (medium)
- L (Low)
-
- Table 1 ISO 7498/Part 2: Security Addendum -- NBS OSI Workshop
- Summary Of SIG-SEC Discussions of Security Service Placement, May,
- 1987
-
- Notes: The following notes are for explanation of the above matrix and
- comments.
-
- A security system should be considered to be an integrated set of
- security services that are placed at selected OSI layers. The
- services should be selected based on a risk analysis for the computer
- system being protected. Security mechanisms must be then chosen that
- will provide the security services and incorporated in the software
- and hardware of the computer system and controlled by the OSI software
- and hardware at the selected layer(s).
-
- For example, authentication, access control, confidentiality and
- integrity are selected as the major security goals for an OSI system.
- A connection oriented transport protocol is being implemented. An
- example of the use of the Matrix could be in an electronic mail
- system, to illustrate this the following specific services and layers
- were chosen:
-
- Peer entity authentication: Layer 4
- Data origin authentication: Layer 7
-
- Access Control: Layer 7
-
- Connection confidentiality: Layer 4
- Selective field confidentiality: Layer 7
-
- Connection integrity with recovery: Layer 4
- Connectionless integrity: Layer 7
-
- The layer 7 services were chosen to support the mail system that would
- protect the selective paragraphs of an electronic message as directed
- by the user. A mail system is considered connectionless. Access
- control is a function of only layer 7.
-
- The layer 4 services were chosen to provide a reliable transport
- service from the sender to the intended receive of the electronic
- message. A full connection integrity and confidentiality service with
- peer entity authentication will assure that all information gets to
- the receiver correctly and confidentially.
-
- Note: The security protocols and mechanisms that provide these
- services are beyond the scope of this Chapter at this time. The
- mechanisms and standards for their interoperability are presently
- being defined and will be added to this Chapter as they become
- available.
- 11. REFERENCES
-
- Selected references are grouped by organization publishing the documents
- and by Reference Model layer to aid relating standards to the OSI Basic
- Reference Model and to aid relating equivalent standards published by
- different standards organizations.
-
- 10. OBJECT IDENTIFIER: STRUCTURE AND ALLOCATION
-
-
- In order to complete a stable version of the NBS OSI Implementation
- Agreements, the following objects need to be administered by an ad
- hoc registration authority:
-
- Application Context Name
- Abstract Syntax Name
- Transfer Syntax Name
- Document Type Name
- Constraint Set Name
- File Model
-
- Since all objects to be administered by the NBS Workshop SIGs are
- identified by the ASN.1 type OBJECT IDENTIFIER, the following
- structure shall be used:
-
- Using the NameAndNumberForm (::= identifier (NumberForm) ) for an
- ObjIdComponent we have:
-
- ObjectIdentifierValue ::= { identifier1 (NumberForm1)
- identifier2 (NumberForm2)
- identifier3 (NumberForm3)
- identifier4 (NumberForm4)
- identifier5 (NumberForm5)
- identifier6 (NumberForm6) }
-
- The assignment of identifiers and NumberForms is as follows:
-
-
- identifier1 NumberForm1
-
- iso 1
-
- identifier2 NumberForm2
-
- identified-organization 3
-
- identifier3 NumberForm3
-
- issuing-organization 9999
-
- identifier4 NumberForm4
-
- organization-code 1
-
- identifier5 NumberForm5
-
- application-context 1
- abstract-syntax 2
- file model 3
- constraint-set 4
- document-type 5
- transfer-syntax 6
- ftam-nil-ap-title 7
-
-
- Note 1: The value of NumberForm3 is selected for use by implementors
- of these agreements: it has not been assigned by ISO or by
- any official Registration Authority. It does correspond to
- an "ad hoc" issuing organization with an ICD of 9999, as
- specified by ISO 6523. We intend to use the procedure
- designated in D.7 of the Specification of ASN.1, ISO 8824
- once the appropriate Registration Authority has been
- established. This mechanism is subject to change dependent
- upon ISO standards.
-
- Note 2: Specific values for identifier6 and NumberForm6 are chosen
- as needed by the . A table of the currently allocated
- values is given later.
-
- Note 3: The NBS UL SIG will assign values for identifier5 and
- NumberForm5 as required by other SIGs.
-
- Note 4: Companies wishing to interoperate may designate themselves
- with an organization code other than 1 under
- { iso (1) identified-organization (3) -
- issuing-organization (9999) } for the purpose of defining
- private OBJECT IDENTIFIERs.
- Table 10.1 TABLE OF ALLOCATED OBJECT IDENTIFIERS
-
- The values of the first 4 NumberForms are constant, so the following
- value is defined for use in the table below.
-
- nbs-ad-hoc OBJECT IDENTIFIER ::= {1 3 9999 1}
-
- Note that the only OBJECT IDENTIFIERS herein defined all begin with "nbs-
- ad-hoc"; all other OBJECT IDENTIFIERS and their associated
- ObjeceDescriptor's are reproduced here solely for the convenience of
- implementors. The standards defining these OBJECT IDENTIFIERSs and
- ObjectDescriptor's take precedence over the values specified below.
-
-
- Application Context
-
- "ISO FTAM"
- { iso (1) standard (0) 8571 application-context (1) iso-ftam (1)
- }
-
- Abstract Syntax
-
- "FTAM PCI"
- { iso (1) standard (0) 8571 abstract-syntax (2) ftam-pci (1) }
-
- "FTAM FADU"
- { iso (1) standard (0) 8571 abstract-syntax (2) ftam-fadu (2) }
-
- "FTAM unstructured text abstract syntax"
-
- { iso (1) standard (0) 8571 abstract-syntax (2) unstructured-text
- (3) }
-
- "FTAM unstructured binary abstract syntax"
-
- { iso (1) standard (0) 8571 abstract-syntax (2) unstructured-
- binary (4) }
-
- "NBS abstract syntax AS1"
-
- { nbs-ad-hoc abstract-syntax (2) nbs-as1 (1) }
-
- "NBS file directory entry abstract syntax"
-
- { nbs-ad-hoc abstract-syntax (2) nbs-as2 (2) }
-
- "ISO 8650-ACSE1"
-
- { joint-iso-ccitt association-control (2) abstract-syntax (1)
- apdus (0) version1 (1) }
-
- "Directory Services"
-
-
- File Model
-
- "FTAM hierarchical file model"
- { iso (1) standard (0) 8571 file-model (3) hierarchical (1) }
-
-
- Constraint Set
-
- "FTAM unstructured constraint set"
- { iso (1) standard (0) 8571 constraint-set (4) unstructured (1) }
-
- "FTAM sequential flat constraint set"
- { iso (1) standard (0) 8571 constraint-set (4) sequential-flat
- (2) }
- "FTAM ordered flat constraint set"
- { iso (1) standard (0) 8571 constraint-set (4) ordered-flat (3) }
-
- "NBS ordered flat constraint set"
- { nbs-ad-hoc constraint-set (4) nbs_ordered-flat (3) }
-
- Document Type
-
- "ISO FTAM unstructured text"
- { iso (1) standard (0) 8571 document-type (5) unstructured-text
- (1) }
-
- "ISO FTAM sequential text"
- { iso (1) standard (0) 8571 document-type (5) sequential-text (2)
- }
-
- "ISO FTAM unstructured binary"
- { iso (1) standard (0) 8571 document-type (5) unstructured-binary
- (3) }
-
- "NBS-6 FTAM sequential file"
- { nbs-ad-hoc document-type (5) sequential (6) }
-
- "NBS-7 FTAM random access file"
- { nbs-ad-hoc document-type (5) random-file (7) }
-
- "NBS-8 FTAM indexed file"
- { nbs-ad-hoc document-type (5) indexed-file (8) }
-
- "NBS-9 FTAM file directory file"
- { nbs-ad-hoc document-type (5) file-directory (9) }
-
- Transfer Syntax
-
- " Basic Encoding of a single ASN.1 type"
- { joint-iso-ccitt (2) asn1 (1) basic-encoding (1) }
-
-
- Miscellaneous
-
- "nil AP Title"
- { nbs-ad-hoc ftam-nil-ap-title (7) }
-
-
- 10.1 Specific ASE Requirements for ACSE Presentation and Session
-
- The following list for each ASE the corresponding NBS SIGs
- requirements of and restrictions on ACSE, Presentation, and Session.
-
- All listed requirements and restrictions shall be included in an NBS
- conformant system and shall be implemented in accordance with these
- NBS Implementor's agreements.
-
- All OBJECT IDENTIFIERS are specified in terms of their associated
- ObjectDescriptor's. See the chapter on OBJECT IDENTIFIERs for the
- values of the associated OBJECT IDENTIFIERs.
-
-
- 10.1.1 FTAM
-
-
- 10.1.1.1 Phase 2
-
- ACSE Requirements:
- all
-
- Application Contexts:
- o "ISO FTAM" - implies the use of the
- ACSE and the FTAM ASE.
-
- Abstract Syntaxes:
- o "ISO 8650-ACSE1"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- Presentation Requirements:
-
- Presentation Functional Units:
- o kernel
-
- Presentation Contexts:
- o At least 4 Presentation Contexts
- must be supported.
-
- Abstract Syntaxes:
-
- o "FTAM-PCI"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type:
-
- o "FTAM-FADU"
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
-
- o "FTAM unstructured text abstract
- syntax"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- o "FTAM unstructured binary abstract
- syntax"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single Asn.1 type"
-
- o "NBS abstract syntax AS1"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- o "NBS file directory entry abstract
- syntax"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single Asn.1 type"
-
- o "NBS file directory entry abstract
- syntax"
-
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single Asn.1 type"
-
-
- Session Requirements:
-
- Session Functional Units:
- o kernel
- o duplex
-
- Version Number: 2
-
- Maximum size of User Data parameter field:
- 10,240
-
-
- Session Options:
-
- Session Functional Units:
- o resynchronize
- only a Resynchronize Type
- value of "abandon"
-
- o minor synchronize
- Note: The minor
- synchronize
- functional unit is
- required whenever
- the resynchronize
- functional unit is
- available.
-
-
- 10.1.2 MHS
-
-
- 10.1.2.1 Phase 1
-
- Session Requirements:
-
- Session Functional Units:
- o kernel
- o half-duplex
- o exceptions
- o activity management
- o minor synchronize
-
- Version Number: 1
-
- Maximum size of User Data parameter field:
- 512
-
- Session Notes:
- o Restricted use is made by the RTS
- of the session services implied by
- the functional units selected.
- Specifically,
-
- . No use is made of S-TOKEN-
- GIVE, and
- . S-PLEASE-TOKENS only asks for
- the data token.
-
- o In the S-CONNECT SPDU, the Initial
- Serial Number should not be
- present.
-
- o The format of the Connection
- Identifier in the S-CONNECT SPDU is
- described in Version 5 of the
- X.400-Series Implementors' Guide.
-
- 10.1.3 DS
-
-
- 10.1.3.1 Phase 1
-
-
- ACSE Requirements:
- all
-
- Application Context:
-
- Abstract Syntaxes:
- o "ISO 8650-ACSE1"
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- o "Directory Services"
- Associated Transfer Syntax:
- o "Basic Encoding of a
- single ASN.1 type"
-
- Presentation Requirements:
-
- Presentation Functional Units:
- o kernel
-
- Presentation Contexts:
- o At least 2 Presentation Contexts
- must be supported.
-
- Session Requirements:
-
- Session Functional Units
- o kernel
- o duplex
-
- Version Number:2
-
- Maximum size of User Data parameter field:
- 10,240
-
-
- 11.1 CCITT
-
- Network Layer
-
- CCITT Recommendation X.25 - 1980, Interface Between Data Terminal
- Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for
- Terminals Operating in the Packet Mode on Public Data Networks.
-
- CCITT Recommendation X.25 - 1984, Interface Between Data Terminal
- Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for
- Terminals Operating in the Packet Mode on Public Data Networks.
-
-
- Transport Layer
-
- CCITT Recommendation X.214, (Red Book, 1984), Transport Service
- Definition for Open Systems Interconnection for CCITT Applications.
-
- CCITT Recommendation X.224, (Red Book, 1984), Transport Protocol Profile
- for Open Systems Interconnection for CCITT Applications.
-
-
- Session Layer
-
- CCITT Recommendation X.215, (Red Book, 1984), Session Service Definition
- for Open Systems Interconnection for CCITT Applications.
-
- CCITT Recommendation X.225, (Red Book, 1984), Session Protocol Profile
- for Open Systems Interconnection for CCITT Applications.
-
-
- Presentation
-
- CCITT Recommendation T.50, (Red Book, 1984), International Alphabet No.
- 5.
-
-
- Application Layer -- MHS
-
- CCITT Recommendation X.400, (Red Book, 1984), Message Handling Systems:
- System Model-Service Elements.
-
- CCITT Recommendation X.401, (Red Book, 1984), Message Handling Systems:
- Basic Service Elements and Optional User Facilities.
-
- CCITT Recommendation X.408, (Red Book, 1984), Message Handling Systems:
- Encoded Information Type Conversion Rules.
-
- CCITT Recommendation X.409, (Red Book, 1984), Message Handling Systems:
- Presentation Transfer Syntax and Notation.
-
- CCITT Recommendation X.410, (Red Book, 1984), Message Handling Systems:
- Remote Operations and Reliable Transfer Server.
-
- CCITT Recommendation X.411, (Red Book, 1984), Message Handling Systems:
- Message Transfer Layer.
-
- CCITT Recommendation X.420, (Red Book, 1984), Message
- Handling Systems: Interpersonal Messaging User Agent Layer.
-
- CCITT Recommendation X.430, (Red Book, 1984), Message Handling Systems:
- Access Protocol for Teletex Terminals.
-
-
-
- 11.2 ISO
-
- Status of ISO work can be determined by the reference number; working
- drafts are referenced by committee and number; e.g., TC 97/SC 6 Nxxxx.
- Standards are cited by either ISO xxxx or IS xxxx; DIS and DPs are cited
- in similar form. Note: ISO TC 97 is now called ISO/IEC JTC1.
-
- Information Processing Systems - Open Systems Interconnection - Basic
- Reference Model. ISO/IS 7498. First Edition - Oct. 15, 1984. Ref. No.
- ISO 7498-1984(E).
-
- OSI Basic Reference Model - Part 2: Security Architecture. ISO/DIS
- 7498-2 TC 97/SC 21/N1895. Project 97.21.18. May 1987.
-
- OSI Basic Reference Model - Part 3: Naming and Addressing. ISO/DIS 7498-
- 3, ISO/TC 97/ SC 21 N2141. May, 1987.
-
- Data Interchange - Structure for the identification of organizations.
- ISO 6523. 1984-02-01.
-
-
- Physical Layer
-
- Information Processing Systems - Local Area Networks - Part 3: Carrier
- Sense Multiple Access with Collision Detection (CSMA/CD) and Physical
- Layer Specification ISO/DIS 8802/3
-
- Information Processing Systems - Local Area Networks - Part 4:
- Token-Passing Bus Access Method and Physical Layer Specification,
- ISO/DIS 8802/4
-
- Information Processing Systems - Local Area Networks - Part 5: Token-Ring
- Access Method and Physical Layer Specification ISO/DIS 8802/5
-
- ISO 8802-5 Final Text of ISO/DIS 8802-5: Info proc systems - Local Area
- Nets -Part 5: Token ring access method and physical layer specification,
- ISO/TC 97/SC 6 N4477,1987
-
- Data Link Layer
-
- Information Processing Systems - Local Area Networks - Part 2: Logical
- Link Control ISO/DIS 8802/2 1985
-
- ISO 8802-2 Text for ISO/DIS 8802-2.2, Logical Link Control, ISO/TC 97/SC
- 6 N4609, 1987
-
- Information Processing Systems - Data Communications - High-Level Data
- Link Control Procedures - Description of the X.25 LAPB-compatible DTE
- Data Link Procedures, IS 7776.
-
- Network Layer
-
- Information Processing Systems - Open Systems Interconnection - Network
- Service Definition, IS 8348.
-
- Information Processing Systems - Open Systems Interconnection - Addendum
- to the Network Service Definition Covering Connectionless Data
- Transmission, IS 8348/AD1.
-
- Information Processing Systems - Open Systems Interconnection - Addendum
- to the Network Service Definition Covering Network Layer Addressing,
- IS 8348/AD2.
-
- Information Processing Systems - Open Systems Interconnection - Internal
- Organization of the Network Layer, DIS 8648.
-
- Information Processing Systems - Open Systems Interconnection - Protocol
- for Providing the Connectionless Network Service, IS 8473.
-
- Information Processing Systems - Open Systems Interconnection -Addendumto
- IS 8473 - Provision of the Underlying Service Assumed by ISO 8473, ISO TC
- 97/SC 6 N 3453.
-
- Information Processing Systems - Open Systems Interconnection, Working
- Draft, End System to Intermediate System Routing Exchange Protocol for
- use in Conjunction with ISO 8473 ISO/DIS 9542 TC 97/SC 6 N 4053.
-
- Information Processing Systems - Open Systems Interconnection - Data
- Communications - X.25 Packet Level Protocol for Data Terminal Equipment,
- IS 8208.
-
- Information Processing Systems - Open Systems Interconnection - Data
- Communications - Use of X.25 to provide the OSI Connection-mode Network
- Service DIS 8878
-
-
- Transport Layer
-
- Information Processing Systems - Open Systems Interconnection - Transport
- Service Definition, IS 8072.
-
- Information Processing Systems - Open Systems Interconnection - Transport
- Protocol Specification, IS 8072, 1984.
-
-
- Session Layer
-
- Information Processing Systems - Open Systems Interconnection - Basic
- Connection Oriented Session Service Definition, ISO 8326: 1987 (E).
-
- Information Processing Systems - Open Systems Interconnection - Basic
- Connection Oriented Session Protocol Specification, ISO 8327 8326: 1987
- (E).
-
- Information Processing Systems - OSI - Basic Oriented Session Service
- Definition - DAD 2 to ISO 8326 to Incorporate Unlimited User Data,
- ISO/IS 8326. Aug. 27, 1987.
-
- Information Processing Systems - OSI - Basic Oriented Session Protocol
- Specification - DAD 2 to ISO 8327 to Incorporate Unlimited User Data,
- ISO/IS 8327. Aug. 27, 1987.
-
- Information Processing Systems - Open Systems Interconnection - Basic
- Connection Oriented Session Service Definition-AD 2 to ISO 8326 to
- Incorporate Unlimited User Data, ISO/IEC JTC1/SC21 N2494.
-
- Information Processing Systems - Open Systems Interconnection - Basic
- Connection Oriented Session Protocol Specification - AD 2 to ISO 8327 to
- Incorporate Unlimited User Data, ISO/IEC JTC1/SC21 N2495.
-
-
- Note: The Session DAD2 Documents This Document, SC21 1987,
- may also be obtained from:
-
- Standards Resource Librarian
- AT&T Bell Labs
- IM304
- Crawfords Corner Rd.
- Holmdel, NJ
- 07733
-
- Presentation Layer
-
- Information Processing Systems - Open Systems Interconnection -
- Connection-Oriented Presentation Service Definition, ISO 8822: 1987 (E),
- (ISO/TC97/SC21 N 2335). Note: until final text is available, reference
- Proof G.
-
- Information Processing Systems - Open Systems Interconnection -
- Connection Oriented Presentation Protocol Specification, ISO 8823: 1987
- (E), (ISO/TC97/SC21 N 2336). Note: until final text is available,
- reference Proof G.
-
- Information Processing Systems - Open Systems Interconnection -
- Specification of Abstract Syntax Notation One (ASN.1), ISO 8824: 1987
- (E).
-
- Information Processing Systems - Open Systems Interconnection -
- Specification of Basic Encoding Rules for Abstract Syntax Notation
- (ASN.1), ISO 8825: 1987 (E).
-
- 7-bit Coded Character Set for Information Processing Interchange, ISO
- 646.
-
- Information Interchange - Representation of Local Time Differentials,
- ISO 3307.
-
-
- Application Layer
-
- Information Processing Systems - Open Systems Interconnection -
- Application Layer Structure, ISO/DP 9545, ISO/TC97/SC21/N1743. July 24,
- 1987. Revised November 1987.
-
- Application Layer -- FTAM
-
- Information Processing Systems - Open Systems Interconnection - File
- Transfer, Access and Management Part I: General Introduction, ISO 8571-1:
- 1987 (E) (ISO/TC97/SC21 N 2331).
-
- Information Processing Systems - Open Systems Interconnection - File
- Transfer, Access and Management Part 2: Virtual Filestore Definition, ISO
- 8571-2: 1987 (E) (ISO/TC97/SC21 N 2332).
-
- Information Processing Systems - Open Systems Interconnection - File
- Transfer, Access and Management Part 3: The File Service Definition, ISO
- 8571-3: 1987 (E) (ISO/TC97/SC21 N 2333).
-
- Information Processing Systems - Open Systems Interconnection - File
- Transfer, Access and Management Part 4: File Protocol Specification, ISO
- 8571-4: 1987 (E) (ISO/TC97/SC21 N 2334).
-
- Application Layer -- ASE/ACSE
-
- Information Processing Systems - Open Systems Interconnection - Service
- Definition for the Association Control Service Element, ISO 8649: 1987
- (E) (ISO/IEC JTC1/SC21 N2326) (ISO/TC97/SC21 N)
-
- Information Processing Systems - Open Systems Interconnection - Protocol
- Specification for the Association Control Service Element, ISO 8650:
- 1987 (E) (ISO/IEC JTC1/SC21 N2327) (ISO/TC97/SC21 N)
-
-
- Application Layer -- VTP
-
- Information Processing Systems - Open Systems Interconnection - Virtual
- Terminal Service - Basic Class, IS 9040.
-
- Information Processing Systems - Open Systems Interconnection - Virtual
- Terminal Protocol - Basic Class, IS 9041.
-
- Application Process -- Office Document Interchange -- ODA/ODIF
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 1; General
- Information, DIS 8613/1.
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 2; Document
- Structures, DIS 8613/2.
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 3; Document
- Processing Reference Model, DIS 8613/3.
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 4; Document
- Profile, DIS 8613/4.
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 5; Office
- Document Interchange Format, DIS 8613/5.
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 6; Character
- Content Architecture, DIS 8613/6.
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 7; Raster
- Graphics Content Architecture, DP 8316/7.
-
- Information Processing Systems - Text and Office Systems - Office
- Document Architecture (ODA) and Interchange Format - Part 8; Geometric
- Graphics Content Architecture, DP 8613/8.
-
- Information Processing Systems - Text and Office Systems - Standard
- Generalized Markup Language (SGML), IS 8879.
-
- Application Process -- Computer Graphics -- CGM/GKS
-
- Information Processing Systems - Computer Graphics - Metafile (CGM) for
- the Storage and Transfer of Picture Description Information, Part 1;
- Functional Specification, IS 8632/1
-
- Information Processing Systems - Computer Graphics - Metafile (CGM) for
- the Storage and Transfer of Picture Description Information, Part 2;
- Character Encoding, IS 8632/2
-
- Information Processing Systems - Computer Graphics - Metafile (CGM) for
- the Storage and Transfer of Picture Description Information, Part 3;
- Binary Encoding, IS 8632/3.
-
- Information Processing Systems - Computer Graphics - Metafile (CGM) for
- the Storage and Transfer of Picture Description Information, Part 4;
- Clear Text Encoding, IS 8632/4.
-
- Information Processing Systems - Font and Character Information
- Interchange, IS 9541.
-
- Information Processing Systems - 8-Bit Single Byte Coded Graphic
- Character Sets, Part 1; Latin Alphabet Part 1, IS 8859/1.
-
- Information Processing Systems - Computer Graphics Functional
- Specification of the Graphical Kernel System (GKS), IS 7942.
-
- Information Processing Systems - Computer Graphics - Graphical Kernel
- System for Three Dimensions (GKS-3D), Functional Description, DIS 8805.
-
- Information Processing Systems - Computer Graphics - Programmers
- Hierarchical Interactive Graphics System (PHIGS), DP 9592.
-
- Information Processing Systems - Computer Graphics - Interfacing
- Techniques for Dialogues with Graphical Devices (CGI),ISO TC 97/SC 21 N
- 1179.
-
- Application Layer -- Directory Services
-
- The Directory--Overview of Concepts, Models, and Services (CCITT
- Recommendation X.500, ISO 9594)
-
- The Directory--Information Framework (CCITT Recommendation X.501, ISO
- 9594)
-
- The Directory--Access and System Services Definition (CCITT
- Recommendation X.511, ISO 9594)
-
- The Directory--Procedures For Distributed Operation (CCITT
- Recommendation X.518, ISO 9594)
-
- The Directory--Access and System Protocols Specification (CCITT
- Recommendation X.519, ISO 9594)
-
- The Directory--Selected Attribute Types (CCITT Recommendation X.520, ISO
- 9594)
-
- The Directory--Selected Object Classes (CCITT Recommendation X.521, ISO
- 9594)
-
- The Directory--Authentication Framework (CCITT Recommendation X.509, ISO
- 9594)
-
- Remote Operations-Part 1: Model, Notation and Service Definition (CCITT
- Recommendation X.219, ISO 9072 Version 5)
-
- Remote Operations-Part 2: Protocol Specification (CCITT Recommendation
- X.229, ISO 9072 Version 5)
-
- Association Control-Service Definition (CCITT Recommendation X217, ISO
- 8649)
-
- Association Control-Protocol Definition (CCITT Recommendation X.217, ISO
- 8650)
-
- Note: ISO 9594, 9072 are preferred texts (over the CCITT counterparts)
- and are to be taken as of Gloucester, Nov. 1987.
-
- CCITT documents may be obtained from:
- International Telecommunications Union
- Place des Nations, CH 1211,
- Geneva 20 SWITZERLAND
-
- ISO documents may be obtained from:
- Frances E. Schrotter
- ANSI
- ISO TC 97/SC 6 Secretariat
- l430 Broadway
- New York, NY. 10018
-
- 11.3 IEEE
-
- Physical Layer
-
- IEEE Standard for Local Area Networks: Carrier Sense Multiple Access
- with Collision Detection (CSMA/CD) and Physical Layer Specification,
- ANSI/IEEE Standard 802.3 1985, Institute of Electrical and Electronics
- Engineers, 345 East 47th St., New York, NY. 10017, 1985.
-
- IEEE Standard for Local Area Networks: Supplements to Carrier Sense
- Multiple Access with Collision Detection (CSMA/CD) Access Method and
- Physical Layer Specification ANSI.IEEE Standard 802.3a, b, c, e -1988
-
- Supplement a, MAU and Baseband Medium Specification, Type 10BASE2
- (Section 10)
-
- Supplement a, Broadband MAU & Medium Specification, Type 10BROAD36
- (Section 11)
-
- Supplement c, Repeater Set and Repeater Unit Specification for Use with
- 10BASE5 and 10 BASE2 Networks
-
-
- Supplement e, Physical Signaling, Medium Attachment, and Baseband Medium
- Specification, Type 10BASE5
-
- IEEE Standard for Local Area Networks: Token-Passing Bus Access Method
- and Physical Layer Specification, ANSI/IEEE Standard 802.4 - 1985, 802.4
- Draft 1987, Institute of Electrical and Electronics Engineers, 345 East
- 47th St., New York, NY. 10017, 1985.
-
- IEEE Standard for Local Area Networks: Token-Ring Access Method,
- ANSI/IEEE Standard 802.5-1985 1986, Institute of Electrical and
- Electronics Engineers, 345 East 47th St., New York, NY. 10017, 1985.
-
-
- Data Link Layer
-
- IEEE Standard for Local Area Networks: Logical Link Control, ANSI/IEEE
- Standard 802.2 - 1985 1987, Institute of Electrical and Electronics
- Engineers, 345 East 47th St., New York, NY. 10017, 1985.
-
- 11.4 NBS
-
- Local Area Networks: Baseband Carrier Sense Multiple Access with
- Collision Detection Access Method and Physical Layer Profiles and Link
- Layer Protocol, FIPS l07, NTIS, U.S. Department of Commerce, 5285 Port
- Royal Road, Springfield, VA. 22l6l.
-
- Interface Between Data Terminal Equipment (DTE) and
- DataCircuit-Terminating Equipment (DCE) For Operation With
- Packet-Switched Data Communications Networks, FIPS l00, NTIS, U.S.
- Department of Commerce, 5285 Port Royal Road, Springfield, VA. 22l6l.
-
- Implementation Agreements for Open Systems Interconnection Protocols:
- NBS Workshop for Implementors of Open Systems Interconnection, National
- Bureau of Standards, NBSIR 86-3385-6, Robert Rosenthal, Editor, Revised
- July 1987.
-
- Implementation Agreements Among Participants of OSINET, National Bureau
- of Standards, Institute for Computer Sciences and Technology, NBSIR
- 86-3478, 1987.
-
- U. S. Government Open Systems Interconnection Profile (GOSIP),
- National Bureau of Standards, Institute for Computer Sciences and
- Technology, 1987.
-
- NBS documents may be obtained from:
- NTIS
- U.S. Department of Commerce
- 5285 Port Royal Road
- Springfield, VA. 22l6l.
- or
- National Bureau of Standards
- Institute for Computer Sciences and Technology
- Gaithersburg, MD. 20899
-
-
- 11.5 MAP
-
- Manufacturing Automation Protocol, General Motors
- Corporation,Manufacturing Engineering and Development, Advanced Product
- and Manufacturing Engineering Staff (APMES), APMES A/MD-39, GM Technical
- Center, Warren, MI. 48090-9040.
-
-
- 11.6 TOP
-
- Technical and Office Protocols Specification Version 3.0, MAP/TOP Users
- Group, Attention TOP 3.0 Document. One SME Drive, P.O. Box 930, Dearborn
- Mi. 48121.
-
- 11.7 CEN/CENELEC
-
- FTAM Draft Functional Standard A/111 (prENV 41 204) Simple File Transfer-
- Unstructrued, 1987-12-01.
-
- ENV 41201 "Private Message Handling Systems"
-
- ENV 41202 "Public Message Handling Systems"
-
-
- 11.8 SPAG
-
- FTAM Draft Profile A/112 Positional File Transfer - Flat, 1987-120-7.
-
- FTAM Draft Profile A/122 Positional File Access - Flat, 1987-12-07.
-
- FTAM Draft Profile A/13 File Management, 1987-12-07.
-
- READER RESPONSE FORM
-
-
- Please retain my name for the next mailing of the NBS/OSI Implementors
- Workshop.
-
-
-
- ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
- 3 3
- 3NAME 3
- 3 3
- 3ADDRESS 3
- 3 3
- 3 3
- 3 3
- 3 3
- 3 3
- 3PHONE NO. 3
- 3 3
- @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
-
-
-
-
- Mail this page to: National Bureau of Standards
- NBS Workshop for Implementors of OSI
- Bldg. 225/B-217
- Gaithersburg, MD 20899
-
-